spf-discuss
[Top] [All Lists]

Re: SUBMITTER is a bad idea

2004-06-06 13:27:31
Seth Goodman wrote:

This snippet of 2821 is easily misconstrued out of context.

Yes, I didn't read the complete text, but only the part about
"depecated features of RfC 821", not expecting anything else
for source routes.

|6.1 Reliable Delivery and Replies by Email
[...]
|    If the address is an explicit source route, it MUST be
|    stripped down to its final hop.
|
|    For example, suppose that an error notification must be
|    sent for a message that arrived with:
|
|      MAIL FROM:<@a,@b:user(_at_)d>
|
|   The notification message MUST be sent using:
|
|      RCPT TO:<user(_at_)d>

This seems pretty clear that you cannot send the DSN to "@a".

It's not completely clear, in the case of a bang path a!b!...
you would send it a.  And the example in RfC 821 starts with a
mail sent from joe(_at_)hostw to sam(_at_)hostz via hostx and hosty.

That's mail to <@hostx,@hosty:sam(_at_)hostz> if I got it right.

They then assume that hostz rejected this mail, because there
is no sam(_at_)hostz(_dot_)  Now hosty bounces this message to hostx and
example 7 in RfC 821 shows the session between hosty and hostx:

  S: MAIL FROM:<>
  R: 250 ok
  S: RCPT TO:<@HOSTX.ARPA:JOE(_at_)HOSTW(_dot_)ARPA>
  R: 250 ok
  S: DATA
  R: 354 send the mail data, end with .
  S: Date: 23 Oct 81 11:22:33
  S: From: SMTP(_at_)HOSTY(_dot_)ARPA
  S: To: JOE(_at_)HOSTW(_dot_)ARPA
  S: Subject: Mail System Problem
  S:
  S:   Sorry JOE, your message to SAM(_at_)HOSTZ(_dot_)ARPA lost.
  S:   HOSTZ.ARPA said this:
  S:    "550 No Such User"
  S: .
  R: 250 ok

And appendix C in 2821 says "read 821" ;-)  Unfortunately I
don't find the reason, why 2821 uses another RCPT TO than 821.

Even if it was permitted, who would you send it to at that
domain?

2821 says <joe(_at_)hostw>, 821 says RCPT TO:<@hostx:joe(_at_)hostw>.

And that's probably the problem:  821 was obviously wrong, it
makes no sense to say RCPT TO:<@hostx:joe(_at_)hostw> while talking
with hostx.  2821 tried to fix it by removing @hostx, and made
it worse.  Of course _one_ host has to be removed, but not all.
Remaining hosts in the path should be kept.  Or what's the idea
of stripping _all_ hosts in 2821 ?

When you mention that SRS solves this problem, it only does
so if _all_ forwarders implement SRS.

As far as I'm concerned forwarders could use a normal MIME
message/rfc822 and use their own headers in any kind they wish.
As long as they don't forge a SPF protected MAIL FROM and don't
cause bounces to innocent bystanders it's none of my business.

comments made it clear that most people considered SRS as
overly complicated, too different from existing practice
and a hindrance to adoption.

I don't insist on it.  I only insist on the one and only
promise made by SPF:  No more bounces to innocent bystanders
as long as the original sender (or rather the MSA) and the
final recipient (the MX) use SPF.  Without this one and only
promise SPF would be useless.
                               Bye, Frank



<Prev in Thread] Current Thread [Next in Thread>