Host name conventions might be simple but they are not standard and not
extensible.
What happens the next time we want to extend SMTP?
-----Original Message-----
From: Douglas Otis [mailto:dotis(_at_)mail-abuse(_dot_)org]
Sent: Tuesday, August 08, 2006 2:14 PM
To: Hallam-Baker, Phillip
Cc: Scott Kitterman; ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] Signalling DKIM support before DATA
On Aug 8, 2006, at 10:54 AM, Hallam-Baker, Phillip wrote:
The way to do this (if it should be done) would be to use the SMTP
extension mechanism.
For example. Define a command option SDATA, Receiver
advertises it in
response to EHLO, sender uses it to present signed data in place of
DATA.
Might be a better implementation but the point is we should use the
SMTP extension mechanism not invent our own.
Something a bit simpler that would not require changing the
MTA code. Use a host-name convention. This would be
apparent at the EHLO without requiring negotiations. In
essences, _dkim.mx01.example.com makes an assurance that:
1) this host-name will authenticate
2) a DKIM client policy can be applied
In conjunction with the DKIM client policy, there could also
be MAIL_FROM policies that offer name relationships. For
example, this list might be a PTR RRset of names. This might
be a lookup of the (_DKIM-MP.<mail-from-domain>, PTR) If a
truncation occurs, a subsequent lookup of the (<query-
domain>._DKIM-MP.<mail-from-domain>, PTR) extends this list
indefinitely.
A domain name of "." might signal that the list is closed.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html