I was going to reply with something like "You don't really mean *MATCH*
type match, do you? What about VERP?" But Jim covered most of the points I
would make.
--Jim Ramsay <i(_dot_)am(_at_)jimramsay(_dot_)com> wrote:
I would suggest that maybe an explicit match is too strict. My
explanation is long-winded, so please bear with me :)
[...]
I propose a way of matching the Envelope to the Headers "within reason":
That is, if the domain is mostly the same, and the front-part is mostly
the same, consider it "first-class". For example, I think this could be
considered close enough to say that an email is "first-class":
This might be too permissive for my tastes. In general I don't like
assuming that a domain name is "close enough" - in my mind it is either the
same domain or it isn't.
Taking into account VERP and SRS and other schemes where the return path
may be different from the From: or Sender: headers, we may still want to
give bonus points for both From: and Return-Path being in the same domain.
Here are some additional ideas to ponder:
1. SPF validates MAIL FROM as usual.
2. Apply the same SPF rules to Sender: if present. Sender: may be a
different domain, in which case use another domain's SPF record.
2a. If it doesn't pass, that's OK, SPF was designed to work with MAIL
FROM. Don't reject the message, but don't improve its placement either.
(In time we may decide to reject messages if Sender: returns "fail" but
this takes some testing and careful thought.)
2b. If Sender: check passes its own check, this is a good thing. There
may be cases where Sender: passes SPF checks and MAIL FROM had only
"unknown". Possibly improve the mail's placement or score.
2c. If both Sender: and MAIL FROM are in the SAME domain, the first
valuable correlation is achieved. Promote the message from third-class to
second-class.
3. Apply the same SPF rules to From: if present.
3a. If From: doesn't pass SPF checks on its domain, don't panic, the
message was probably relayed by a list or may have come from the user's
home, hotel, or coffee shop instead of his work network. Don't reject, but
don't improve its placement either. (There may be extreme cases where
certain domains *want* extreme From: checking, like banks, where the role
address should never send to a mailing list and should never have any other
Sender: or return path changes done to it.. If the sending domain really
wants extreme From: checking we could make a modifier for it, but save that
for future)
3b. If From: matches its check, in addition to or instead of MAIL FROM
or Sender: this is highly valuable data, but not quite enough to make it
first class.
3c. If From: is in the SAME domain as MAIL FROM, and BOTH checks passed
(not just unknown) this is true first class (certified) mail.
Anyway, the point is, instead of checking:
SPF (MAIL FROM)
Sender: ~= MAIL FROM
From: ~= MAIL FROM
I would instead do something like:
SPF (MAIL FROM)
SPF (Sender:)
SPF (From:)
Domain(MAIL FROM) = Domain(Sender:) and both PASS: Second class
Domain(MAIL FROM) = Domain(From:) and both PASS: First class
Another way to think about this is, Sender: is a fallback for From: in a
similar way to HELO is a fallback if MAIL FROM: <>
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>