Section 5.1 describes the problem; is that satisfactory?
Sorry, I'd either missed or forgotten that. 5.1 doesn't say what the
problem is, though, it just says that traditionally the sender address
is left untouched. It talks about 'preserving return-path
functionality', but it doesn't spell out the obvious, ie ensuring that
the mail gets there in the first place.
I think it's worth spelling out the scenario in so many words, for the
benefit of readers who are new to designated sender schemes: A sends
to B, who forwards to C preserving the envelope, who applies an SPF
check and rejects the message because it doesn't come from one of A's
designated senders.
What's obvious to us isn't necessarily going to be obvious to someone
who's encountering the idea for the first time.
Assigning fault is not within the scope of an RFC
Hmm, I'm not sure I agree. When two systems can claim conformance
with an RFC, and yet fail to interoperate with each other, we have a
problem. A well designed spec should be able to identify which of the
systems is failing to conform (ie whose fault it is).
Let me put it another way. I think it would be good for the draft to
clarify, for the avoidance of doubt, that if example.com publishes SPF
records, the only claim they are making is that they will not
originate mail from IP addresses other than those described by their
SPF records. They are making no other claim. In particular, they are
clearly not making the claim that no MTA on the internet will ever
receive mail from them from an IP address that is not described by
their SPF policy. Such a claim would be nonsensical, since they have
no knowledge as to how the mail might be treated after they've sent
it.
This is obvious to you and me, but again, it's worth spelling it out
for the benefit of people new to the concepts.
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.
C claims he's doing nothing wrong, he's simply verifying the sender
according to the SPF spec.
So, all three systems are RFC-compliant, and yet the mail bounces.
This is untenable, IMHO. User A really will send a mail to user C, it
really will bounce, and each of the three ISP's will blaim the others.
And all three ISP's really will be complying with the RFCs. And
situations like this will give SPF a bad rep.
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.
-roy
-------
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;±¤Ö¤Íµø?¡