spf-discuss
[Top] [All Lists]

Re: MUST SPF checking be done during SMTP time?

2005-05-14 08:15:24
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mark wrote:
-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com] On Behalf Of Chuck 
Mead
Sent: zaterdag 14 mei 2005 15:16
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: Re: [spf-discuss] MUST SPF checking be done during SMTP time?



On the one hand, Chuck is correct in that this is the
"right thing" to do,  because during the SMTP transaction,
the required identities are _reliably_ known, and "Received-SPF"
headers can be generated for applications that need to "check"
SPF at a later time.

On the other hand, there is little reason why checking SPF
at a later time is _inherently_ worse. Systems don't necessarily
have to use unreliable identities after SMTP time. Systems
don't necessarily have to generate bounces after SMTP time. As long
as you are guaranteed to work on reliable identities, you can be
SPF compliant. (Also, whether bounces are  generated is outside the
scope of SPF, even though it is unsocial behavior. Recommend against
it if you wish, but not in RFC 2119 terms.)

I think we should go the latter route, but it is not a
strong preference.

We keep talking about this as though there is nothing wrong with
bouncing and as though we're concerned about implementation like
spamassassin. I have nothing against spamassassin but it is *NOT*
directly concerned with what we're trying to accomplish with our
protocol description.


After a fashion, this issue is rather similar to the much heated
discussion on whether the SPF spec should concern itself with saying that
checks against other identities is NOT RECOMMENDED, in that we are facing
a similar question. So, should the SPF spec state that using SPF checks
outside the SMTP dialogue is NOT RECOMMENDED? I think it should. Or, at
least, I think it should be clearly understood why it is not recommended.

To name a reason, things like "TempError" and "PermError" have no real
meaning outside the SMTP dialogue, as the message has already been
accepted for delivery. Other than sending an ex post facto bounce --
which, at that point, is really nothing more than an entirely new message
-- "TempError" and "PermError" no longer pertain to the already completed
SMTP transaction; and, in fact, yield the rather bizarre situation of
first accepting the message, and then creating a 'manual' bounce for it
anyway.

In fact, section 2.4 "Checking Authorization" already says:

"Software SHOULD perform this authorization check during the processing of
the SMTP transaction that injects the mail. This allows errors to be
returned directly to the injecting server by way of SMTP replies. Software
can perform the check as early as the MAIL command, though it may be
easier to delay the check to some later stage of the transaction.

Software can perform the authorization after the corresponding SMTP
transaction has completed. There are two problems with this approach: 1)
It may be difficult to accurately extract all the required information
such as client IP address and HELO domain name. 2) If the authorization
fails, then generating a non-delivery notification to the alleged sender
is problematic as such an action would go against the explicit wishes of
the alleged sender."

Not only is generating a non-delivery notification to the alleged sender
problematic, as such an action would go against the explicit wishes of the
alleged sender, but it also goes directly against what your own MTA has
just done: already accepted the message for delivery. So, as far as I am
concerned, I would just drop the entire last paragraph of section 2.4.

With all due respect what *I* am doing mentally is drawing a circle and
placing all things SPF *IN* the circle... all ancillary issues are
outside the circle... once I have done that I say, "What... inside that
circle... needs to be in the spec to have a proper definition for SPF
compliance?" Answering that question means throwing out and deliberately
excluding any and all concerns not directly related to the protocol
define and it's necessary controls.

- --
csm(_at_)moongroup(_dot_)com, head geek
http://moongroup.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFChhYMv6Gjsf2pQ0oRAqOPAJ4vXUcNj59tbHmr205DEdqy+cJTPACghHSH
FzkWjvroTuett0cm8pjWDZw=
=E3nw
-----END PGP SIGNATURE-----