On Tue, 19 Oct 2004, Stuart D. Gathman wrote:
On Tue, 19 Oct 2004, william(at)elan.net wrote:
Here is the syntax I could come up with in last 30 minutes (requires new
macros, specific for this type of header equivalency checking):
[...snip...]
The operands mean:
d - match domain portion of header's email address to domain part of
mail-from
l - match full email address of mail-from to full address in header
n - never matches (means the email can't have this header)
a - always matches, this is default and basicly means any header value
matches
With 3 new macros:
%{hn} - header name (i.e. "sender" or "from")
%{hl} - header's domain full address with local part (i.e. like %{l})
%{hd} - header's domain without local part (i.e. like %{d})
This is a great idea for rfc2822. IMHO, however, the MAIL FROM domain
should not be setting the policy for the RFC2822 sender. I think that
the RFC2822 sender domain should have their own record stating which
MAIL FROM domains are authorized to send mail for them.
I'll note though that for many small domains its just going to be same
one-one correspondence - for 95% of internet emais the mail-from is
in fact same as either Sender or From (especially if we base it solely
on domain portion and full email address). In fact as far as I know
hotmail and couple other webmail servers actually have (or had?) default
anti-spam policies in which they try to match mail-from to From: and
anything else is considered unwanted email (this required whitelisting
every mail-list which was real pain).
That would have the additional advantage of not cluttering MAIL FROM
authentication with rfc2822 stuff.
I dont think its cluttering and my personal opinion we should avoid having
RFC2822 stuff in SPF in the first place. The reason why I put it into SPF
classic/mail-from is because in this match system the headers (and multiple
ones as specified) are matched to SMTP2821 mail-from and I want to allow
the same to be done for SMTP2821 SUBMITTER scope identity in the future.
The rfc2822 record would not be fetched until after SMTP DATA (because
you won't know which domain to check until then).
The proposed modifier syntax is pretty short, so its ok to fetch it
together with SPF mail-from and cache it for data stage. But for
additional lookups if there is redirect is expected, extra lookups
would be done after SMTP DATA.
And note that I actually intended this modifer not be for SMTP servers
but for email content analyzers and filters like SpamAssasin or
Mimedefang and for for MUAs. But obviously if MTAs want to do these
checks, they are welcome to it too.
As for why the MAIL FROM domain should not set policy for the RFC2822
domain, consider the SPF compliant domain spammer.com which says they
are allowed to send mail with the 'From: accounts(_at_)victim(_dot_)com'
header.
I see your point and its very good one because what you describe does
allow spammer to lie and get authenticated into RFC2822 access based on
some other domain and email that may not be displayed to the user.
This makes me think that doing it with domain-list may not be worth it
and its better to just have system that can either say that domains in
Mail-From and From/Sender are supposed to be the same or not and as I
originally and if they are not, the sender is expected to use cryptography
for authentication of his RFC2822 data.
If we actually do it the other way around as you suggest, that is
basicly SenderID with its own set of problems that are now well known.
Or am I misunderstanding the proposal? Is the proposal to lookup
the SPF record for the header from domain, and use the new modifiers
to validate the header From, while ignoring the MAIL FROM mechanisms?
(Instead of simply creating a new record type for validating headers.)
The proposal is to match RFC2821 MAIL-FROM to headers Sender and From
(and possibly to other headers). It is based on requirement of doing
RFC2821 MAIL-FROM verification and skips necessity of verifying RFC2822
fields separatelt with their own SPF records and instead provides record
where RFC2821 mail-from policies let it be known that RFC2822 email address
is supposed to be the same (or have the same base domain).
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net