----- Original Message -----
From: "Julian Mehnle" <bulk(_at_)mehnle(_dot_)net>
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Saturday, February 26, 2005 11:00 AM
Subject: RE: [spf-discuss] SPF Setup Peculiarities For Megapathdsl
Scott Kitterman wrote:
I have recently discovered that megapathdsl.com checks all mail
(inbound and outbound) for SPF. They then apply the Received-spf
header. They only reject inbound failures.
Foremost, a "Received-SPF:" header should not be added as a result of an
_outbound_ SPF check. The header name kind of implies that.
Sure it can. The outgoing mail should be checked for forged webmail or spam
traffic, since often people can accidentally get their laptops zombi-loaded
or virus-laden when they travel or take it home. It will get replaced at the
next SPF compliant SMTP server. And remember, an outbound SMTP server may
also be a POP or IMAP server for locally stored email.
Distinguishing between the filtering inbound and the filtering outbound is
often adding complexity and debugging confusion, since mail that works from
inside will work outside or vice versa.
Now one might assume that receivers would ignore Received-SPF headers
applied by previous MTAs. That is not always correct.
In the first place, only receiver _MUAs_, not MTAs, should care about the
"Received-SPF:" header. Then, a receiver MUA should look at only those
"Received-SPF:" headers of which it is absolutely sure that they have been
genuinely added by the receiving MTA. This is usually only the single
topmost header, _if_ the receiving MTA adds such a header at all.
The receiving MTA should, in theory, also become SPF capable and do its own
SPF check.
There is no point in "blindly" looking for any "Received-SPF:" headers in
a received message, not knowing whether the receiving MTA actually added
those. This might be a sloppiness in SpamAssassin and similar tools (I am
not sure because I don't use SpamAssassin).
Unfortunately, various use simple correlation with the headers to also
provide information, and they're basically correct to do so. If forged SPF
headers become too common on spam, they will actually correlate with spam
for those users and cause problems when the users' upstream MTA starts using
SPF, which is a problem with the header analysis of these clients. But they
can retrain past that quite quickly, so I wouldn't worry about it.