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
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: Shared MTA policy implementation idea, (continued)
- Re: Shared MTA policy implementation idea, wayne
- Re: Shared MTA policy implementation idea, Stuart D. Gathman
- SRS for postfix yet?, Mark Jeftovic
- Re: SRS for postfix yet?, John Capo
- Re: MUST SPF checking be done during SMTP time?,
Chris Haynes <=
- Re: MUST SPF checking be done during SMTP time?, Frank Ellermann
- Re: Re: MUST SPF checking be done during SMTP time?, Chris Haynes
- Re: MUST SPF checking be done during SMTP time?, Julian Mehnle
- Re: MUST SPF checking be done during SMTP time?, Julian Mehnle
- Re: MUST SPF checking be done during SMTP time?, wayne
- Re: Re: MUST SPF checking be done during SMTP time?, wayne
- Size of draft (was: MUST SPF checking be done during SMTP time?), Frank Ellermann
- Re: MUST SPF checking be done during SMTP time?, wayne
- Re: MUST SPF checking be done during SMTP time?, Julian Mehnle
Re: MUST SPF checking be done during SMTP time? (was: patch), Chris Haynes
|
|
|