On Wed, Nov 27, 2013 at 08:01:19PM +0000, Stephen Farrell wrote:
> On 11/27/2013 06:58 PM, Nico Williams wrote:
> > [...]
>
> I'm not sure detecting the path length in terms of ADMDs is so
> easy, not so useful in terms of MTAs (with all the spam checking
Sure it is! Nowadays the path should generally be:
sender's MUA -> sender's MSA
sender's MSA -> sender's MTA (this is generally internal, and
anyways it can be marked as such)
sender's MTA -> recipient's MTA
recipient's MTA -> recipient's mailbox
Internal-to-sender/recipient's-infra hops are irrelevant/uninteresting.
Now, a recipient might use a third-party MX, but the recipient's MUA can
check that the MX RRs for the recipient's domain match the unexpected
path element. (MX RRs can change, which can cause the path validation
results for an e-mail with non-shortest path to change over time.)
> that can go on), nor that the above is really explicable to users.
> We'd need to ask some mail folks.
No need to explain to users. The MUA either validates the path and
marks the mail as verified to be from the sender, or... not. It's a
boolean. Users can be expected to understand a boolean.
Of course, it doesn't help the user that a phisher is "authenticated";
phishers and spammers would be the first to implement this, as with
DKIM. But the MUA can also AND the sender's presence in the recipient's
address book to the expression producing that boolean result.
> But I like the emerging scheme below a good bit more:-)
:)
> The problem with DANE is the lack of DNSSEC. If we had both [...]
When I refer to DANE, I also mean that DNSSEC must be there. We're
getting there.
> Otherwise I think we're in agreement and I'll send a pointer
> to this sub-thread to apps-discuss so follow up can happen
> there. (I think you're on that list right?)
I am. Thanks for sending this there.
Nico
--
_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography
