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. That would have the additional
advantage of not cluttering MAIL FROM authentication with rfc2822 stuff.
The rfc2822 record would not be fetched until after SMTP DATA (because
you won't know which domain to check until then).
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.
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.)
--
Stuart D. Gathman <stuart(_at_)bmsi(_dot_)com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flamis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.