Re: [yam] Issue #10: RFC 5321 3.9: add tiny subsection

[Alessandro Vesely <[e-mail]>]

Ned Freed wrote:
>> Section 3.4 is titled "Forwarding for Address Correction or
>> Updating".  The tiny change you suggested might end up causing confusion.

A .forward is not actually an alias, in facts. However, 3.9.1 
doesn't say what reply code should be returned (250 or 251) for 
aliases, and an implementation may accept foreign addresses for 
aliasing. Does _this_ cause confusion?

>>>I agree that "Backup MX" is a poor title, and I apologize for having 
>>>transferred it as-is from my notes to this list. Its most notable 
>>>defect is that it does not include smart hosts nor other servers 
>>>along the outgoing path. I'd amend the tentatively proposed titles to be
>>>
>>>   Forwarding
>>>     Relaying   <-- "Backup MX" was here
>>>     Aliases
>>>     Mailing lists
>>>
>>>The relationship among these server's activities may now be clearer.
>
>> Quoting Section 3.4:
> 
>>    "Forwarding support is most often required to consolidate and simplify
>>     addresses within, or relative to, some enterprise and less frequently
>>     to establish addresses to link a person's prior address with a
>>     current one."

IMHO, support for changing address is inadequate in most 
implementations.

> Even if I were to grant that there's a close equivalency between backup MX
> handling and alias expansion - which I don't - what was the confusing 
> aspect of this and how does this change help eliminate that confusion?

Recovering a sound definition of the term "forwarding" is the main 
purpose for that change.

One common facet among foreign backup MXes, address changes, aliases 
expansions, and mailing list is that they treat personally 
identifiable information, namely the substituted email addresses. 
Most implementations don't comply with the spirit of privacy laws, 
in that they don't allow the owners of that data to inquiry or 
change it directly. Obviously, I don't think that it would be savvy 
or feasible to embrace privacy laws into the RFC. However, I note 
that although most privacy laws have been formalized after SMTP, 
they are based on the same common sense as RFC 821. Noncompliance 
apparently stems from the introduction of virtual users, and 
obscurely-subscribed mailing lists (a.k.a. spam).

If 5321bis could factor the circumstances where possible 
infringements may formally occur, it might be easier to define some 
SMTP extension, add-on protocol, or mixture thereof in order to fix 
that. For an underdeveloped attempt see http://fixforwarding.org