Aredridel,
I do not believe that the burden imposed by SPF is much higher than
DomainKeys, ...
A> I agree here -- SPF as it's currently specified only checks SMTP-level
A> fields, not headers
That difference does not constitute much of a technical difference to
the software. It's all part of a protocol stream and none is more
difficult to parse.
A> -- it's easy enough to rewrite any third-party
A> service to use their own domain as the sending domain in the MAIL FROM.
MailFrom does not specify the sending domain. It specifies a return
address. It is not appropriate to have intermediaries arbitrarily
changing the return address.
A> SPF also codifies what's rapidly becoming a best practice: rejecting
A> mail that claims to come from one place (domain) when in fact it is
A> coming from an unrelated (and unauthorized) place (specified with a map
that's not distinctive to spf.
A> if MAIL FROM != RFC2822-From, then display as "From:
A> <greetingcards(_at_)example(_dot_)com> on behalf of
<joe(_at_)example(_dot_)org>"
you want the user to be shown the return address, if it does not match
the From field?
A> The main reason I prefer validating MAIL FROM instead of header fields
A> is that it maintains some semblance of layering: RFC2821 specifically
A> tries to avoid relying on RFC{2,}822 semantics too much:
Actually, this has pretty close to nothing to do with layering. You can
model the analysis module at whatever layer is appropriate to the data.
A> SPF-like proposals also scale well
Something that requires pre-registration of all of the places I may send
mail from does not scale all that well. Imagine having to preregister
every telephone you might call from.
d/
--
Dave Crocker <dcrocker-at-brandenburg-dot-com>
Brandenburg InternetWorking <www.brandenburg.com>
Sunnyvale, CA USA <tel:+1.408.246.8253>