On Thu, 2004-09-23 at 19:08, Frank Ellermann wrote:
The potential _abuse_ of Resent-* as dummy PRA is of course one
of several real problems with PRA.
I've never seen this as a serious problem with SenderID over the long
term, given that I want to separately push the idea of sender_agents.
(And I admit I'm doing a bad job of it.)
Let's assume that sender_agents comes about one way or another. (So
that senders--ie, full email addresses--can publish who their authorized
forwarding agents are, for both mailfrom and pra senses--they could also
publish who they accept forwards from in those two scopes, the latter of
which could be useful in a few corner cases unrelated to the issue at
hand.)
In that sender-agents-exists scenario, if an MTA in the middle adds a
new PRA via a possibly-forged resent-* header, then one of the following
has to be true:
1. The domain in that PRA doesn't permit the sending MTA to send
messages with that PRA.
This is not a problem, as SenderID would cause a rejection.
2. The domain in that PRA does permit the sending MTA to send
messages with that PRA:
A. And the recipient has whitelisted the forwarding MTA.
No problem--this is fine.
B. The recipient has *not* whitelisted the forwarding PRA:
i. If the original From: participates in sender_agents
and there's an unbroken sender_agents trust chain going
forward, then fine. MUAs can mark the FROM as believed
to be authentic.
ii. If the original From: participates in sender_agents
but the sender_agents trust chain going forward is
broken, then reject the message.
ii. If the original From: doesn't participate in sender_agents:
a) But some later PRA does, but the chain is broken before
the recipient--reject the message.
b) But some later PRA does, and the chain is unbroken
through to the recipient--the MUA could mark that first
participating PRA as the most recent trusted party.
c) And no later PRA does, then while you have no reason
to reject the message, the MUA must mark the PRA as
the most recent trusted party, if it wants to show
that sort of extra info to the user.
The upshot to all this is that recipients using updated MUAs can see
when From:'s have been validated, not see
definitely-forged-because-of-sender_agents From:'s (since they'd have
been rejected), and see indications of the first/last/any trusted PRA in
between.
An MUA with a simpler display could show from lines as:
(checkmark) From: person(_at_)friend(_dot_)com
Versus:
? From: person(_at_)friend(_dot_)com
Versus:
(Bright-red-X) From: person(_at_)friend(_dot_)com
(The latter in case the recipient set his ISP web-panel control to
disable rejections of failing sender_agents messages--normally these
would have been rejected at mta-transfer time.)
Sender_agents is a test almost completely uncoupled with all the rest of
spf and senderID. It's almost as decoupled as accreditation and
reputation query services, so the fact that it might not exist quite yet
isn't really a problem--it's just IMHO another minor requirement on the
way towards greater authentication/anti-spam/anti-phishing protections.
The original MARID plan was to discuss CSV after "Sender-Id"
(now again SPF), and I have only vague ideas about CSV.
You know, I don't really understand what advantages CSV would gain us
over an imaginary world in which EHLO domain names were required by all
recipients to be resolvable and matching the sending IP.
Although it conflicts a bit with the spf null-sender EHLO check test, I
wonder if a SHOULD requirement for EHLO domain matching, coupled with
that being included in any spf-verification web pages/email test pages,
could help us get to a world where recievers ususally do full resolve
tests on the HELO domain.