At 03:16 PM 6/9/2005 -0400, John Leslie wrote:
David MacQuigg <dmquigg-clear(_at_)yahoo(_dot_)com> wrote:
http://purl.net/macquigg/email/...
]
] EHLO mailserver7.bigforwarder.com
] ID bigforwarder.com
] MAIL FROM:<bob(_at_)sales(_dot_)some-company(_dot_)com>
(omitting the 250-ID response...)
It's in the example in section 5.
There is an interesting issue here for CSV.
This sort of mechanism could be a win for receiving SMTP servers that
do not do the full upward search for SRV records (assuming, of course,
that the "ID" sends a different string than the "EHLO").
I am not sure it's a significant win overall; and I'm not the least
bit sure that we'd have any reason to trust the "ID" string where it
isn't a superdomain of the EHLO string -- unless this draft was changed
to prohibit more than one "ID" per "EHLO".
I was thinking of CSV when I wrote in section 4: "c) Do a cross-check,
then proceed with the declared ID. e.g. The default ID must be a subdomain
of the declared ID." I don't see any fundamental difference in security,
but as a designer of CSV, the identity to check is your choice. It is also
your choice whether to allow the sender to put CSV data in the main record
under <ID>, or insist on doing separate queries for records at each EHLO
identity. Either way it is the ID owner that assumes responsibility for
the transfer.
As for the prohibition on having authentication records at multiple levels
of the EHLO name, you could do that. It's your method and your rules, but
I don't know why you would want to deny this flexibility to the domain
owner. For example, a host under rr.com might have at one time ID
austin.rr.com, and another time ID rr.com. Maybe the admin of rr.com wants
to keep the reputation of the newly-acquired Austin division separate from
the main organization, at least until the new subdomain gets its zombies
under control. As a receiver I care only that there is a reputable ID
willing to accept responsibility for the transfer.
--
Dave
************************************************************ *
* David MacQuigg, PhD email: david_macquigg at yahoo.com * *
* IC Design Engineer phone: USA 520-721-4583 * * *
* Analog Design Methodologies * * *
* 9320 East Mikelyn Lane * * *
* VRS Consulting, P.C. Tucson, Arizona 85710 *
************************************************************ *