------------------------------
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com] On Behalf Of David
MacQuigg
Sent: dinsdag 22 februari 2005 11:08
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: Re: [spf-discuss] Email Forwarder's Protocol ( EFP )
If the IP address is recorded in a header, then a bounce could be sent
even *after* the SMTP session is closed.
Why? An SPF query either passes or fails (in the narrow sense that a
connection is either REJECT-ed/TEMP-failed or passed through). If it
passes, then there is, thereafter, no longer a reason to send a bounce
based on the result of the SPF-query. Right?
Seems to me that an ability
to relay a delayed bounce may be an unavoidable requirement if
forwarders are going to participate in an IP-authenticated transfer.
That is where SRS comes in. :) SRS uses a clever address 'short-cut'
mechanism; and, solely based on REJECTs, ensures a properly signed voyage
home, across multiple forwarders even.
Received-SPF: neutral (mail.bmsi.com: guessing: 202.47.165.130 is
neither permitted nor denied by domain of MTS_PDC.drbhicom.com.my)
The problem with these headers seems to be that nobody likes them :>(
I cannot immediately see why they would then like "Authenticate: SPF1 [<IP
Address>] <senders-domain> PASS" any better. But, apart from that, I think
we should not overestimate the importance of the Received-SPF header, or
variants thereof. I mean, ultimately, you could leave the header out
altogether, and it would not affect the SMTP dialogue one iota; messages
would still either get REJECT-ed/TEMP-failed, or be passed down for
further processing. By the time the recipient takes a look at the mail
headers, what he then sees at that point is merely informative: the
decision to pass the message, by the MTA, was already made a long time
ago.
Now, please do not read me as saying I do not care for the Received-SPF
header, because I do. :) But it is not like I can make a critical decision
based on that information. None of the recipients on my server (in- or
outgoing) will ever see an SPF "fail" in the headers (at least not in a
Received-SPF header I generate). Because if fail were called for, I would
have already REJECT-ed the connection (now, that is barring the discussion
on whether you should actually fail on "fail" -- I think you should, btw
-- because if you're not going to REJECT, then the whole bounce issue is
moot to begin with). Think SA for a moment. If you decide not to "fail" at
the SMTP dialogue, then are you likely to do so, based on the Received-SPF
header, in SA? That would not make much sense. Hence my point: if you're
not going to REJECT at the SMTP stage, then whatever you will use the
Received-SPF header for, it is likely just for gathering statistics.
Cheers,
- Mark
System Administrator Asarian-host.org
---
"If you were supposed to understand it,
we wouldn't call it code." - FedEx