In <200505141408(_dot_)54215(_dot_)bulk(_at_)mehnle(_dot_)net> Julian Mehnle
<bulk(_at_)mehnle(_dot_)net> writes:
Wayne Schlitt wrote:
I did not apply this one. As discussed on #spf, Chuck feels very
strongly about requiring SPF being done during the SMTP transaction
and not during later processing, such as SpamAssassin and other
filters are doing.
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.
I very strongly agree that accepting and then bouncing to addresses
that have been forged is a very bad thing to do. I have advocated
rejecting during the SMTP session for a very long time, and to the
best of my knowledge, it is impossible to get a post-accept bounce out
of my MTA.
There are several reasons why I do not think we should change the
"SHOULD" in "This authorization check SHOULD be performed during the
processing of the SMTP transaction that sends the mail." to a "MUST".
First: off, this is Receiver Policy and I don't think we should
dictate Receiver Policies.
Second: mengwong-spf-0[01] said that you could perform the checks in
the MUA. As I have said before, I consider any argument in the form
of "previous SPF specifications and implementations did XXX, therefore
the current draft should also" to be a strong argument.
Third: There are many existing implementations of SPF that are being
checked after the SMTP transaction is done. As I say in the I-D "The
goal of this document is to clearly document the protocol defined by
earlier drafts specifications of SPF as used in existing
implementations."
Fourth: I have always felt that part of the goal of SPF was to make
bounces useful again, even if they are after the SMTP transaction, as
long as the SPF check didn't fail. Too much legitimate email is
getting lost in spam folders (or /dev/null'ed) instead of being
bounced.
I would support a *different* I-D that mandates that you can't send
bounces to forged email addresses, but I don't think the SPF version 1
I-D is the place to do it.
Anyway, those are my thoughts on the subject. I could see strengthing
the language, but not to the point where we say "MUST".
-wayne