Hector Santos wrote:
In any case, at some point, someone will need to address the legacy SMTP
software issue which is clearly the basis for the exploitation that is going
on. If the SMTP loopholes did not exist, we wouldn't have much a spoofing
problem. We would not be here.
A good starting point would be for example, DK or IIM (for ALL new
proposals) is to introduce new ESMTP keywords that enforce new policies.
IIM can have ESMTP keywords such as:
IIM IIM optional by sender
IIM-R IIM required by sender
IIM-RP IIM required by sender policy (IP, domain based?)
etc.
If we are going to make sense of any new authorization proposal, I think we
need these new types CLIENT/SERVER policies as it will state upfront the
intent of the server both from a technical and more importantly legal
standpoint.
So the client tells the server whether IIM is optional or required? If
the messages are being sent by the same entity making the
optional/client assertion, how is that useful? You need an independent
mechanism for the verifier to get that information out of band and in
such a way that it will survive transparent (.forward) forwarding, which
is what is already described in the IIM (section 6.1.3) and DK (section
3.6) drafts.
-Jim