Instead of authenticating senders, what if we authenticated
sender-domains, leaving it to domains to authenticate senders
(or not)?
That is another equally valid method.
I see a range of possible authentication mechanisms:
Reverse MX - Not cryptographic, can be defeated,
email must be routed through approved outgoing MTA
SSL - Applies to whole domain, strong crypto
email must be routed through approved outgoing MTA
S/MIME - Applies to individual sender, strong crypto
no restrictions on routing.
And of course a trusted third party / CA can add value here but is
not absolutely essential.
I think we need to accept that there is a rationale and a place for
each of these, and possibly new mechanisms that are carefully tailored
to the problem of spam without boiling the secure email ocean.
1) To send mail, Alice uses SMTP to post the message to an
"originating MTA" blessed by her domain. (Of course, we'd all like
to see that domain use an authenticated variant of SMTP to verify
Alice's identity, but if you think about it, this is really a
policy issue that perhaps domains would prefer we left to them.)
Actually this gated model is actualy one that appears as a requirement
in many secure email deployments - the canonical reason eing to add
disclaimers to messages.
The 'end to end' model of security does not address the security
requirements of a lot of financial institutions, the end is the
institution, not Alice or Bob.
Potential advantages of doing this at the domain rather sender level:
I agree, we definitely need the choice. The only reason I backed off
the domain level security scheme was that I didn't want to have yet
more complaints about people not being able to send direct from their
MTA while we discussed the principles.
I am currently working on a broad-based security policy language that
allows any security policy to be advertised through the DNS or other
name/directory system. This is similar to work we are currently doing
with Microsoft, IBM and RSA for Web Services.
Rather than send the draft to the group in its current form I would like
to continue to refine the idea for a while in a small group. My experience
is that it is usualy better if one gets as many bugs out of a proposal
as possible before going for widespread review.
Phill
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg