|
Re: MUST SPF checking be done during SMTP time?
2005-05-16 09:17:03
"Terry Fielder" suggested:
wayne wrote:
In <2ffe01c55889$d5df4430$0600000a(_at_)john> "Chris Haynes"
<chris(_at_)harvington(_dot_)org(_dot_)uk> writes:
I thought this had been discussed and agreed _long_ ago!
This is not my recollection. I went poking around the SPF archive and
the MARID archive and I couldn't find a general consensus on this
issue. However, I could easily have missed some discussions, so if
you can point me to a thread where this issue was resolved, please let
me know.
For what it is worth, this issue of "delayed checking" can be more
than just an issue of MUAs doing checkings. If you send email through
a smart host, and the destination can't be contacted, there can be a
delay of up to a week or two. Similarly, things like greylisting can
cause delays. Some organizations may have a border MTA that then
redirects the emails to various departmental MTAs. These departmental
MTAs can know which Received: headers can be trusted and so they can
accurately do SPF checks, but there may be an arbitrarily long delay
between accepting at the border MTA and the departmental MTA.
Secondary MXes are very similar to the boarder/dept MTA problem.
I guess my point here is that even saying something like "SPF checks
MUST be done during the SMTP session" is far too vague. An email may
go through many SMTP sessions, from the original submission to the
final delivery, and each hop can introduce a delay. If we place all
the burden on the receiving side to do the checking within one DNS
TTL, then that also life hard for senders who use any smart hosts for
any of its email.
Only if the final MTA stays down for longer then the TTL. Do you think that
happens often? Most people running an MTA either have it on a stable
connection (even if it is say cable or DSL), and/or are aware of the lost mail
risks of running an MTA on an unreliable connection that stays down for
extended periods.
I think we could end up with a lot of complicated language trying to
nail all different cases down, when in reality what most people want
is for the probability of a false reject to be very small and that can
be done by both the sender and the receiver trying to do minimize the
problem.
I see the discussion on what to do about policies that change with time.
And I am a proponent of SPF only during SMTP time.
But to keep the others (e.g. SA) happy, how about:
When you evaluate SPF post SMTP, any DNS record you use to determine the
senders policy can only be used if its TTL means that the DNS lookup could
have occurred before the timestamp the message was received by MTA.
I realize this is not perfect, its possible at SMTP time the TTL on the DNS
record was set to say a few minutes, and then a few hours later when the MUA
gets the email the ISP could have finished a migration and have put the TTL
back to say 2 days.
However this is a rare case; generally the lookup result changes more often
then the TTL (the "winding down" example seen earlier as someone prepares to
migrate being the noted exception). But generally when one is prepared enough
to "wind down" for a migration, one is prepared to have an interim policy that
handles the old and new MTA's. Hence no problem.
Just a thought: shoot it out of the water if that is what it deserves. :)
Like you, I'd like to help SA etc. if technically possible, but I think your
proposal does not work.
The TTL just says how much time remains until the record expires. There's no
indication of when it first came into operation, or other means of inferring
whether or not it was valid at some arbitary time in the past.
We would have to use my earlier suggestion of incorporating a time-stamp
modifier into the SPF record itself. Although technically we could do that now,
since a new modifier does not _need_ a new spec version, that would be outside
the spirit of the current exercise of documenting what is current practice, and
what is supported by current software.
Anyway, just for the record, and in case anyone wants to try it out
experimentally, here is a proposal:
--------------
Proposed new modifier VF - Valid From
Syntax:
VF=yyyymmdd[HH[MM]]
where yyyymmdd is a date
HH is an optional hour part in 24-hour form.
MM is an optional appendix to the hour part, indicating the number of minutes
Semantics:
If a the current SPF record for a domain contains the VF modifier, and the
juncture it records is prior to the time at which some SMTP transaction took
place, then this current SPF record MAY be used to evaluate the IP address
involved in that SMTP transaction.
If no VF record is present, or if the juncture it records is later than the time
of the SMTP transaction, then the effect shall be as if there were no SPF record
found for the domain.
If the record makes reference to the record for some other domain (e.g. using
the 'include' mechanism), and it needs to be consulted to determine the sender's
policy , then these semantic rules must be applied to that other policy before
it is used.
The date and time express a juncture in Universal Time (UTC).
Examples:
VF=200505161652 Valid from 4: 52 PM (UTC) on 16 May, 2005
VF=2005051616 Valid from 4: 00 PM (UTC) on 16 May, 2005
VF=20050516 Valid from midnight (UTC) on 16 May, 2005
----------------------------
As I say, this is not a proposal for incorporation into this current spec., but
I thought I'd write it up now, while it's in my mind. Without something like
this, I firmly believe SPF testing should only be recommended during the SMTP
transaction.
Chris Haynes
|
|