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:[EMAIL PROTECTED] > Sent: Tuesday, August 08, 2006 2:14 PM > To: Hallam-Baker, Phillip > Cc: Scott Kitterman; [email protected] > 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
