On Tue, 2004-08-10 at 01:23, Jim Fenton wrote:
There needs to be a chain of trust between where the source of the email
is verified and the recipient. I believe that is needed whether you do
the rewriting I'm describing or not. If that chain of trust exists,
the sender shouldn't be able to forge it.
If we had a sender_agents modifier (or something close), and the
purported previous senders participated in sender_agents, then receiving
MTAs could reject messages with broken chains of trust between the body
header address that the mail purports to originally be made on behalf
of, and the final recipient.
So then the modified MUA displays need only alert people about
"questionable" messages, ie, message that were accepted but for which
either:
o the purported original senders don't participate in sender_agents,
*AND*
there are forwarding PRAs not authorized and white-listed by the
recipient,
(I would think this would be rare for legitimate mails--large
legitimate bulk mailers should have the expertise to properly
participate in sender_agents.)
OR
o The purported original senders do participate in sender_agents,
but the Sender_ID tests don't result in a complete PASS because
of recipient forwarding hops that result in NEUTRAL or SOFTFAIL
answers.
(This problem is under the control of the recipient.)
The end-users wouldn't have to be worry about messages with
provably-forged chain-of-trust forwarding hops, as they'd have been
rejected.
They'd only have to worry about "questionable" mails, and for any
legitimate ones they could go complain to their ISPs who don't do
forwarding properly, or they could complain to the the real sender who
doesn't participate in sender_agents, depending on the circumstance.
That is, in most cases I would think the receipt of legitimate but
"questionable" mails according to the Sender-ID/sender_agents tests
would be a solvable problem given customer feedback.
(For instance, I couldn't imagine citibank and paypal not having spf
records *and* sender_id modifiers in those records, say, 2 years from
now, as their existence could eliminate almost all body-header-address
forgeries using their real domain names in the body From: line.
Obviously you'd need domain-name block lists to catch things like From:
lines with paypa2.com (or with a numeral 1 instead of numeral 2))
(Of course all the above still doesn't address the bounce problems that
classic SPF and SES&SRS handle so well--just the
authorized-by-onbehalfof-person-to-submit problem that SenderID
purportedly addresses. So I'd hope people would do spf classic tests on
MAIL FROM at message receipt as well to address the bounce problem, and
SES/BATV on message transmission to address filter forged bounces
bounced back to you.)
--
Mark Shewmaker
mark(_at_)primefactor(_dot_)com