I do not like the fact that there are now choices for how
to determine the responsible-sender.
In my mind, an MUA that does in-spec spf-checking should
simply fail with "unknown" if there's no Return-Path.
I would prefer people to have to write out-of-spec spf
clients to handle mailboxes written to by broken MTAs,
because if there are multiple ways of figuring out
responsible-sender, some good and some not-so-good,
then in-spec mua-level spf tests can have different
results, making spf seem unreliable.
If instead, in-spec mua-level tests must fail with
an "unknown", and people do out-of-spec workarounds
for folks with buggy mta's, it will be more obvious
to everyone involved that the fundamental problem lies
with the mtas instead of an spf spec that isn't very
specific.
It will then be more clear that the reason these people
can't reliably use spf testing is that they have
a buggy MTA, and they'll more likely to get that fixed
instead of trying more and more workarounds to "fix"
spf testing.
I don't see the point of being accepting of bad data
when you simply can't end up with a useful answer from
the data.
So I would suggest a section 2.2.1 such as the following:
|2.2.1 Terms
|
| This section defines important terms. They can be thought of as
| variables in an SPF client. It is crucial that they be interpreted
| correctly.
|
| The <responsible-sender> MUST be determined using the following
| algorithm:
|
| For SPF processing at SMTP time:
|
| The <responsible-sender> comes from the domain name of the
| "MAIL FROM" envelope sender. When the envelope sender has
| no domain, a client MUST use the HELO domain instead. If the
| HELO argument does not provide an FQDN, SPF processing
| terminates with "unknown".
|
| If the <responsible-sender> has no localpart, clients MUST
| substitute the string "postmaster" for the localpart.
|
| For SPF processing after SMTP time:
|
| The <responsible-sender> comes from the domain name of the
| Return-Path header. If the Return-Path header has no domain,
| SPF processing terminates with "unknown".
|
| If there are multiple Return-Path headers, the second and
| subsequent ones are ignored.
|
| If the <responsible-sender> has no localpart, SPF processing
| terminates with "unknown".
|
| The <current-domain> is initially drawn from the
| <responsible-sender>.
|
| Recursive mechanisms such as Include and Redirect replace the
| initial <current-domain> with another domain. However, they
| do not change the value of the <responsible-sender>. See
| sections 4.2, 3.3, and 8.4.
(I added the bit about multiple Return-Path headers in case spammers
start adding them in themselves--I don't know if MTA's would catch
that.)
(Also, I'm not sure about the 'terminate with "unknown" part for mua's
versus substituting "postmaster".)
--
Mark Shewmaker
mark(_at_)primefactor(_dot_)com
-------
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.9.7.txt
Wiki: http://spfwiki.infinitepenguins.net/pmwiki.php/SenderPermittedFrom/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡