On Tue, Oct 21, 2003 at 12:55:56AM +0100, Roy Badami wrote:
And to put it one final way:
A sends mail to B. B forwards to C, without implementing SRS. C
rejects the mail, because it doesn't come from a designated sender of
A.
Now, A claims he's doing nothing wrong; he's simply publishing SPF
records according to the SPF spec.
B claims he's doing nothing wrong, he's simply forwarding mail
according to RFC2821 and RFC2822.
OK, RFC2822 is no problem. It is dealing *only* with message content, not
envelope. It specifies that people reintroducing messages into the system
SHOULD (a MUST would be nicer, but...) include Resent- fields. If these are
present (and SPF is being applied based on headers), SPF should be applied
based only on the most recent Resent-Sender (or whichever header is being
checked) present in the message. If none is present, then the "vanilla"
header should be used (all this to determine which domain to look up in SPF).
Now, RFC2821. section 3.3 specifies that the reverse-path specified in the MAIL
FROM: command contain the source mailbox, that can be used to report errors.
I admit that it's not terribly clear what is meant by "source mailbox", but
I would argue that the source mailbox is actually related to the system
performing the forwarding, and that the practice of simply inserting the
original source mailbox here is merely a convenience which to date has had
few adverse consequences. To me a reverse-path contains at least some
implication of symmetry with the forward path -- i.e. if it passes through
the forwarder on the forward path, by definition it should also pass through
it on the reverse path.
Note that it is also specified here that the SMTP-receiver may refuse to
accept that reverse path; there is no reason why we cannot give a failure
code (probably 550, with an explanation) here.
I think section 7.1 is more of a problem; the paragraph beginning "Efforts
to make it more difficult..." (and, to the degree that it is talking about
the ability to fake sender information being "useful functionality", the
following paragraph too) we clearly disagree with, and it would probably
be as well to point this out, and justify ourselves. Perhaps in the end this
needs to be superseded :-(
Appendix D scenario 3 is particularly interesting (look at the MAIL FROM:
command in step 2). Perhaps this could be useful?
Anyway, I think it looks like there are two options open to us: either we
assert that it is wrong for systems to provide an asymmetric return-path
(and the only assertion to the contrary I can see in RFC2821 or RFC2822 is
the seriously misguided RFC2821 section 7.1, which does not say that a
return path is not symmetric, it just says "let 'em fake it if they like"),
or we check for Resent- headers in the body of the message and do the
SPF lookup on the most recent resender.
This latter option is more expensive and less elegant, but will not lead
to as many people getting annoyed (I'm not saying whether I think this is
a good or bad thing).
C claims he's doing nothing wrong, he's simply verifying the sender
according to the SPF spec.
Which will clearly be a perfectly reasonable thing to do, if we get it right.
:-)
So, all three systems are RFC-compliant, and yet the mail bounces.
This is untenable, IMHO.
It's actually a desired result, don't forget -- B *is* faking the source
mailbox. We just need to be clear what the "right" way for B to deal with
this is.
I believe the correct way to address this is that receiving systems
which apply SPF checks need to take responsibility for accepting mail
from (non-SRS) accounts that forward to them.
This is clearly completely impossible; there is no way the recipient can
do this, as they cannot know in the general case who will be forwarding to
them.
Cheers,
Nick
-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/draft-mengwong-spf-02.txt
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡