On Mon, 2004-01-26 at 11:53, tv+spf(_at_)duh(_dot_)org wrote:
On Mon, 26 Jan 2004, Mark Shewmaker wrote:
: 2. You then claim that a check at DATA is more expensive, as the
: entire data stream must be sent.
:
: My question is "More expensive than what?":
:
: o More expensive than an envelope check?
:
: Nope: We've already done an envelope check, the message so far
: passed it, and so we're now obliged to receive the entire data
: stream anyway.
Yes, but the expense comes under the assumption that a body check is perhaps
the *only* SPF method provided by the potentially forgeable domain in their
TXT record. If that's the case, then there is no envelope check at all, and
it is indeed more expensive to process that message's SPF authenticity.
I can agree with that.
I was not suggesting that there be any changes in spf1 TXT records. I
was not suggesting that spf1 text records have any reference to
body-versus-header--merely that the standard require and document
envelope checks, and allow and document header/body checks.
That being the case, the situation you mention could not occur for spf1.
However, to be fair, a big reason to allow for body checks in future spf
versions would be to allow for that sort of thing. I was and am hoping
for some spf revision to allow for something such as:
1. "Consider mail purporting to be from my domain to be from my domain
if sent from any of these IPs."
2. "Also consider mail purporting to be from my domain and not from
the above IP's, but containing mumble-mumble signature check in the
headers, to be from my domain."
3. "Otherwise, do not believe any emails that claim to be from my
domain."
So your point is spot-on in that way, as such a method would allow for
lazy domains to only publish public-key or fingerprint type data and no
simple envelope-check type data. It would be...annoying if domains did
that. (As well as an odd sort of lazyness to set up public key
signature fingerprints and valid times and what have you, but not
actually just type in a few valid sending IPs.)
I would like future spf proposals to allow for that sort of traveling
salesman scenario--such sending emails from a domain even if the
authorized outgoing mailservers are down. Intricate debate on how to do
that is probably not timely now, given spf1 spec cleanup. (Although I'm
willing to participate of course. :-) )
However, I would hope that it would be possible to do something like the
above, without the lazy-domain problem you're worried about. (Possibly
the spec disallowing listing keys without also listing valid outgoing
domains; I don't know.)
There has to be some way around the problem you legitimately worry
about--perhaps spf will help to limit the spam problem to such an
extent, freeing up resources on mail servers, that doing mta-level body
checks on every single email will no longer be considered too much
work. :-)
Anyway, your worry not valid for what I was actually proposing at the
time, but it is valid for what I hope can be done at some point.
This is where the whole concept about "allowing senders to be lazy" comes
from. If SPF-authenticated senders are permitted (or worse yet, encouraged)
to do body-only checks, then the lightweight value of SPF is dead in the
water. If using SPF, envelope checks should be mandatory, and body checks
optional as a [secondary] method of reassurance only.
(And, once you reach that point, why include body checks in SPF at all?
What would it buy you?)
I agree for spf1 type checks, especially with my corrected Return-Path:
misunderstanding. (And thank you for continuing to clarify your
reasoning in the face of that hidden misunderstanding.)
--
Mark Shewmaker
mark(_at_)primefactor(_dot_)com
-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/draft-mengwong-spf-02.9.4.txt
Wiki:
http://spfwiki.infinitepenguins.net/pmwiki.php/SenderPermittedFrom/HomePage
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡