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

[SM <[e-mail]>]

Hi Alessandro,
At 02:50 07-12-2009, Alessandro Vesely wrote:
>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?

Please see Section 3.4 for a discussion of the 251 code.  Section 3.9 
begins with:

   "An SMTP-capable host SHOULD support both the alias and the list
    models of address expansion for multiple delivery."

There is also:

   "An important mail facility is a mechanism for multi-destination
    delivery of a single message, by transforming (or "expanding" or
    "exploding") a pseudo-mailbox address into a list of destination
    mailbox addresses."

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

Are you sure that fits under Section 3.9?

>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

That's a creative way to start a discussion about that four letter word. :-)

Regards,
-sm