On Tue, 22 Feb 2005, David Woodhouse wrote:
On Tue, 2005-02-22 at 00:19 -0500, Stuart D. Gathman wrote:
Can SPF disrupt the delivery of valid eMail?
No. It only disrupts the delivery of email with forged MAIL FROM.
Stuart is being somewhat disingenuous with his use of the word 'forged'.
What he refers to as 'forgery' is in fact common practice. When users
SPF only blocks delivery of email that the sender has specifically
defined as forged via their published SPF record. I am not being
disingenuous. By not publishing an SPF record, you implicitly tell
SPF recipients that you have no policy - either because your policy
cannot be expressed in the SPF framework, or because of political reasons -
and presto, none of your email is blocked by SPF.
forward mail from one site (a vanity domain, old university, old
employer etc.) to a real mailbox elsewhere, it's almost always done with
the original sender's address intact. That's what Stuart calls
'forgery'. And SPF breaks it.
Only broken SPF breaks it. An SPF record for a vanity domain easily
enables that domain, designating authorized servers if possible. In fact,
doing nothing and not publishing a record enables that domain for any server.
SPF does not stop email from being delivered to recipients that don't check
SPF. If does not stop email from being delivered to recipients that
properly check SPF either. A huge todo has been made over certain
common configuration errors (e.g. failing to configure non-SRS forwarders)
- when simply providing a FAQ telling newbies how to avoid those errors would
be much more helpful.
See http://david.woodhou.se/why-not-spf.html for further discussion and
some alternative schemes which you might want to consider instead, which
don't have such problems.
Any scheme has problems when not implemented correctly. All your complaints
have been against bad implementations or (most often) bad configurations - and
do not apply to the SPF protocol itself. This is known as a straw man
argument.
You could try claiming that SPF is too complex to implement or configure
correctly (a complaint I've made myself against C++), but the reality is that
SPF is quite simple, and the common mistakes made are technically simple, and
simple to correct if not for all the misinformation and FUD flying around.
There is a simple option for recipients: check SPF, and add the Received-SPF
header, but don't reject anything. This will let you observe your
configuration over a long period of time to be sure you've accounted
for all your non-SRS forwarders, etc.
--
Stuart D. Gathman <stuart(_at_)bmsi(_dot_)com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flamis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.