spf-discuss
[Top] [All Lists]

Re: MUST SPF checking be done during SMTP time?

2005-05-15 00:24:12

"wayne" mused:

In <200505141427(_dot_)j4EERRZ2063686(_at_)asarian-host(_dot_)net> Mark <admin(_at_)asarian-host(_dot_)net> writes:

           I would just drop the entire last paragraph of section 2.4.

I think that it is important to leave the last paragraph in because it
gives reasons why you SHOULD perform the SPF check during the SMTP
transaction.  I think it could, however, do a better job of making
that point.  In particular the last paragraph starts out with "oftware
can also perform the authorization after the corresponding SMTP
transaction has completed."

I've been playing around with the last paragraph, and section 2.4 now
ends with this:


  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.


Again, I'm kind of playing around with this, I'm really not set on
this wording.  Comments are very welcome.  I was very tempted to point
out that bogus bounces can (now) be reported to spamcop and can get
your MTA listed on their DNSBL.  ;-)



Please take note of the integrity issue I raised, and that Frank and I have been debating.

My assertion is that, if checking is to be done after SMTP time, that late checking MUST however be done with a copy of the SPF policy taken _during_ the SMTP transaction.

Doing the SPF policy look-up at some time after the SMTP phase can get totally wrong results, if the policy has changed.

Overnight I've thought of a quite plausible scenario which demonstrates this...

Suppose you have an ISP who assigns IP addresses dynamically, along with a suitably-smart DNS system. Their customers wish to send their mail directly from their own systems, using their own domains (which the ISP knows about). The smart DNS sets up a transient SPF policy which authorises this, and the IP address it authorises is valid only during the extent of the dial-up connection. As soon as the customer disconnects, her SPF policy (which had a zero TTL) is removed from the DNS.


I'm being insistent here on this point because, while SPF was 'experimental' we could have wording which just coped with 'most normal' cases. In moving to a production RFC you have got to have wording which preserves the integrity of your system under all conceivable cases. Sampling the SPF policy during the SMTP transaction is essential for that integrity.

Note that I'm not proposing banning _testing_ after SMTP time, just insisting that the SPF record used in any late test MUST have been sampled at SMTP time.

I know this means that some current systems like SpamAssassin would be in contravention of the new RFC, but you can't bend the logic of integrity and completeness just because something popular is taking risks and laying itself open to false decisions - however infrequently that might happen.

If you (collectively) insist on permitting post-SMTP reading of the policy, then I would argue that you would have to add some kind of explicit 'valid-from-until' time stamps within the SPF record itself, which testers would be required to check against the time-stamp of the SMTP transaction. You would also have to transmit all previous versions of the policy every time, over a period of , say one month, and say that late SPF testing must be done within this window. All previous versions of the policy for that month, as well as the 'current' one, would have to be supplied within the TXT look-up! Believe me, you don't want to go there - and could not as part of SPF1.

You have got to insist that the SPF policy is collected from the DNS _during_ the SMTP transaction. That's the only way of ensuring integrity within the overall SPF1 design.

Chris Haynes