"Alan DeKok" responded:
"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 recipient is invited to accept that the message _is_ from the purported
domain because the Sender's Policy says he should - she has declared that shared
MTA trustworthy. It's her message, her policy, her choice of shared MTA.
When the recipient is offered the message he extracts the domain of the
Mail-From and consults the DNS for that domain to get the policy. He then
applies the policy 'algorithm' to the IP address of the sending MTA to see if it
was authorised by the sender, and, if so, what the 'strength' of the sender's
policy is on this particular MTA.
If her policy says 'pass' ('+'). then she is saying 'If this MTA offers you a
message purporting to be from my domain, I trust it, and so should you'.
The receiver has to trust:
1) The DNS service to deliver the correct SPF policy for the domain
2) The IP transport system to report accurately the IP address of the sending
MTA.
There his need to trust anything associated with the shared MTA ends.
The message has been identified as coming from the sender's domain, and the
sender has accepted responsibility for the behaviour of the MTA.
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.
I invite you to be specific about this second trust relationship you talk of.
Just what is it that the reciever has to trust the sending MTA to do or not do,
and which is not covered by the sender's trust in that MTA?
A specific example would help me understand your concern.
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.
Agreed - I don't think I was advocating a 'binary' value in the trust itself,
was I?
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.
That's what I have started above.
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.
If you intend this as a criticism of SPF then you have to expose these unspoken
assumptions.
Please be specific.
Let me explain where I'm coming from:
I'm not associated with any one scheme. I'm a 'sufferer' who needs a workable,
engineeringly-viable solution.
I see in SPF something that's pretty neat - I like its architecture, the one
which keeps the sender in charge of the policy. But I can also see problems with
it, e.g. with whether the _sender's_ trust in an MTA not under her
administrative control can ever be well-founded.
There appear to be several other schemes being proposed in this space. At the
time of the chairs' choosing I'll be just as interested in them.
I think those who have alternative schemes to offer are being put in a difficult
position by the procedure that has been adopted in this WG. We are being
invited to consider the candidates one by one. This goes agains all my
engineering instincts, which are to:
a) Agree the objectives and metrics of success,
b) Identify all viable candidates,
c) Assess them in parallel against the objectives, constructing interesting
scenarios, test cases etc. - against which all candidates can be evaluated.
Instead we have a procedure which feels as if it could end with a winner being
declared as soon as the first 'just about acceptable' solution has been
identified.
Those proponents of candidate solutions which have not yet been considered
probably feel the need to continually draw attention to the defects of those
candidates which were lucky enough to be considered first. This is challenging
because the points of difference are difficult to describe when you are not
allowed to be specific about the 'better' approach which you cannot yet talk
about.
So I have a lot of sympathy for those proponents waiting to get their candidate
exposed.
But I, for one, feel that any criticism of a scheme which _is_ on the table has
to be phrased in very concrete terms. There has to be a specific example of a
weakness, of a security vulnerability etc. for the rest of us to be able to
understand the concern.
It may well be that you can see some specific weakness in the use of Mail-From
that the rest of us cannot see and that you can do the WG a service by exposing
that specific weakness. I've been trying to manoeuvre you into doing this with
your 'trust' concern. I'm genuinely trying to understand the 'space' in which
the receiver's trust or mistrust of the sending MTA matters to you.
What is it that the sending MTA can do or not do which, whilst still honoring
the trust that the sender has in that MTA, causes Mail-From to be flawed?
Alan DeKok.
Chris Haynes