-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Julian Mehnle wrote:
Chris Haynes wrote:
If so, please propose the rule we should include in the RFC to define
for how long after SMTP-time the test will still be valid, and justify
your proposal.
There should be no hard limit because, according to experience, few
policies vary over time. [...]
Uhm, no. That should have read "vary within the period of time that SPF
checks are usually done in, ather the SMTP transaction". But of course
that's practically just as fuzzy as not declaring any limit whatsoever...
Wayne Schlitt suggested:
| This authorization check SHOULD be performed during the processing of
| the SMTP transaction that sends the mail. This allows errors to be
| returned directly to the sending server by way of SMTP replies.
|
| Performing the authorization after the corresponding SMTP transaction
| has completed faces problems, such as: 1) It may be difficult to
| accurately extract the required information from potentially
| deceptive headers. 2) If the email is forged and the authorization
| fails, then generating a non-delivery notification to the alleged
| sender is abusive and is against their explicit wishes.
Re 1: some systems supply the relevant identities through environment
variables, which _is_ accurate. Thus I'd just say ""
Re 2: This sentence insinuates that performing an SPF check after SMTP time
means that the receiver still wants to "reject" the message, which would
then imply generating a bounce. This is not generally correct, some
receivers may just want to mark the message. The fact that many receivers
generate bounces to unauthenticated sender addresses is no reason at all
to generally recommend against after-SMTP-time SPF checks. In fact, many
systems _always_ generate bounces instead of giving negative SMTP replies.
This is not a matter of when SPF checks are performed. Instead we should
_generally_ recommend, outside this particular paragraph, against sending
automatic messages to sender identities that have not been authenticated
(through SPFv1 or other means).
I propose:
Generally, the sender policy can only be assumed to be applicable
during the SMTP transaction transporting the given message. As a
result, this authorization check SHOULD be performed during the
processing of the SMTP transaction that sends the mail. This also
allows errors to be returned directly to the sending server by way of
SMTP replies.
Performing the authentication check after the corresponding SMTP
transaction has completed faces problems, such as: 1) the identity
owner's sender policy may have changed since the transaction completed.
2) It may be difficult to accurately determine the required identities.
Generating non-delivery notifications to forged identities that have
failed the authentication check is generally abusive and against the
explicit wishes of the identity owner.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
iD8DBQFCh2z1wL7PKlBZWjsRAiBzAKC1RhxfqKUBaScVEHT+B5INCqVt9QCfSQje
B14RDcSd/43fAMBhP5cpRlY=
=+jUK
-----END PGP SIGNATURE-----