"Chris Haynes" <chris(_at_)harvington(_dot_)org(_dot_)uk> wrote:
When I say "originator trusts the shared MTA" I mean "trusts the
shared MTA to have authenticated and identified the sender of each
message (using SMTP AUTH or equivalent),
The recipient can verify that the originator intends the shared MTA
to use "MAIL FROM" it's domain. The recipient cannot tell if any
individual message sent by that shared MTA is actually from the
alleged originating domain.
The "trust" you mention above includes two separate trust
relationships, only one of which can be verified by the recipient. To
me, this means we should talk about the trust relationships in
isolation, and not together.
It also means that a binary trust value for the shared MTA is
inadequate. A "trusted" value can be used for MTA's you control, an
"untrusted" value for MTA's you don't like, and a "maybe" value could
be used for shared MTA's. As noted earlier, this is being done today
with SPF.
I can't understand the basis of your concern about a "weakness in any MAIL
FROM..." .
I'm looking at it from the view of the recipient, and from an
examination of what information is available, and what things are
being trusted. We can say that publishing a "MAIL FROM"
authentication record has the meaning you intend, but that meaning
contains pieces ("trusted" message origin) that contains claims by the
originator which cannot be verified by the recipient. In contrast,
the "trusted to use MAIL FROM with my name" claim CAN be verified by
the recipient: he has a connection where the shared MTA is using MAIL
FROM with that name.
My method is a bit reductionist: divide everything into small
pieces, and examine how those pieces are used, and how they're put
togther. Only when we understand the pieces can we be confident that
a system built on those pieces does what we want.
The alternative is to build a "house of sand". It's pretty, but
with no foundations. It will collapse as soon as one of the unspoken
assumptions is questioned, or proven wrong.
Alan DeKok.