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

[Ned Freed <[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.

I never said anything about .forward files - nor did I say what you quote
above, sm did.

> 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?

Not in my experience, no.

> >>>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.

That presupposes the existing definition is unsound. I disagree that it is.

> 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.

Even if I grant that there's a sufficiently serious issue with control over
forwarding entries by the recipient of that entry that work needs to be done to
solve - which I absolutely do not believe to be the case - what I'm misssing
here is even the remotest scintilla of justification for bringing this up in
the context of 5321bis.

If you want to make a proposal regarding changing how forwarding works, you
need to do it the old fashioned way - write a draft describing the problem and
your porposed solution, and then see if you can get sufficient support for your
idea  for it to be placed on the standards track.

You don't do it by engaing in some sort of wierd gambit involving changing the
definition of forwarding.

> 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

Or it might not. Your crystal ball must be very clear indeed to be able
to predict how such a change would affect such a proposal.

In any case, I've made my position clear - I'm opposed to this particular
change.

				Ned