Re: Comments on DSP/RR/SPF drafts

2nd try.  apparently attachments get eaten.

On Mon, Oct 27, 2003 at 09:41:08PM -0800, Raymie Stata wrote:
| The volume of mail on asrg has prevented me from following the
| discussion closely.  I'm sure what I say below has been addressed
| at length.
| 
| At the same time, you eventually will be sending your drafts to
| people who aren't on ASRG at all.  So take the following as 
| comments you're likely to get from such an outsider.
| 
| Raymie
| 
| 
| ** Comment one
| 
| Section 8.4 of Fecyk's draft states:
| 
|    This author recognizes that every MTA using .forward files on *ix
|    hosts or similar configurations do not alter the sender envelope
|    when forwarding mail.  However, commercial and proprietary mail-
|    forwarding systems such as mail.com[tm] alter the sender envelope,
|    and these are by far the most popular pure mail-forwarding
|    instances.
| 
|    There is no fix for .forward usage aside from altering the sender
|    envelope and designating the forwarding host as a Designated Mailer
|    for itself, as described in 5.2 above.
| 
| Section 10.3 of Danisch's draft is similar:
| 
|    Therefore, it is required that, when performing untrusted
|    forwarding, the envelope sender address has to be replaced by the
|    sender address of someone responsible for the relaying mechanism,
|    e.g. the owner of the mailing list or the mail address of the user
|    who's .forward caused the transmission.  It is important to stress
|    that untrusted relaying/forwarding means taking over responsibility
|    for the message.  ...
| 
| Section 5.2 of Wong's proposal contains similar language.
| 
| First, Facyk's claim disagrees with my experience.  I have four
| aliases I uses regularly -- one powered by the post.office MTA,
| another powered by Mirapoint's MTA, and two (@acm.org and
| @alum.mit.edu) whose software is unknown to me.  NONE of those
| change the reverse-path of mail that is forwarded to me.  The
| number of people who used the above listed MTAs and/or forwarding
| services is very large: this is not a "*ix hackers .forward
| problem" -- it's much bigger than that.
| 
| BTW, this behavior is completely in keeping with section 3.10.1 of
| rfc2821: "To expand an alias, the recipient mailer simply replaces the
| pseudo-mailbox address in the envelope with each of the expanded
| addresses in turn; the rest of the envelope and the message body are
| left unchanged."  Thus, one would expect that pretty much every
| forwarding mechanism around to keep the original message's
| reverse-path (aka, "envelope sender").  In otherwords, to repeat,
| this isn't simply a ".forward" problem.
| 
| Finally, RFC2821 is very clear that the reverse-path is where delivery
| notifications are to be sent.  All three drafts attempt to change
| these semantics (to "responsible party") without really highlighting
| the fact that they're doing this.  Again, for schools and
| organizations
| and services that run forwarding services, this will require a
| significant change to their infrastructure.
| 
| For example, if one of
| your schemes takes off, and universities (for example) want to
| continue their "email address for life" programs (which, BTW, almost
| all major universities now have), then those universities will have to
| implement a bounce-management system that, among other things,
| includes figuring out how to bounce messages back to the original
| error-delivery mailbox.  This is a major addition of complexity
| (that can't be solved by simply running mailman).
| 
| I'm sure you've heard all this before, and my goal isn't to force you
| to rehash old arguments.  However, as a comments on all three
| _documents_, let me say that they all come across very glib on this
| point, like they are sweeping an important but inconvenient
| issue under the rug.
| 
| 
| ** Comment two
| 
| I wonder if the solution to the above problem might not be to avoid it
| altogether: use DNS to validate the relaying
| SMTP server (from the HE/EHLO greeting) rather than the return-path.
| (The Wong draft mentions this idea but doesn't really focus on it.)
| 
| At first, it may seem that this provides significantly weaker
| protection than does validating the reverse-path.  However, all
| the reverse-path proposals really do is prevent someone from using
| some random machine as a spam
| mill.  The proposals do NOT prevent a spammer from obtaining a new
| domain, appropriately setting up DNS records for that domain, and then
| spamming away.
| 
| Validating the SMTP server names given in the SMTP
| greeting does the same thing.  It prevents a spammer from using a
| random machine as a spam mill, although it does not prevent a
| determined spammer from setting up a "spam domain."
| 
| Just something to think about.
|