Mark, you tell me we shouldn't have extensive discussion on this list, but
then keep raising new and interesting questions. I'll continue to reply,
but let's change the subject line. If we come up with some new objection,
something that can be presented in a short, rational statement, we'll
append to the old thread.
At 11:53 AM 5/25/2005 +0000, Mark wrote:
David MacQuigg wrote:
> Mark Shewmaker wrote:
> > Your ID, otoh, is no more
> > than a glorified extra HELO; and who needs that?
>
> !!! Where did you get this? The new ID *can* be the same as the HELO
> identity, but probably only the CSV folks will insist on that.
If the CSV folks would insist on ID being the same as HELO, then they
would insist on the uselessness of ID. :) And, in fact, CSV bases
everything, including reputation, on the EHLO string (or a
derivative thereof;) like so:
mailhost IN A 199.201.159.9
IN PTR _vouch._smtp.csv_vouch
_client._smtp.mailhost SRV 1 2 0 mailhost
Exit ID.
If the CSV folks were to insist that the ID be the same as the EHLO
identity, they would not make it useless, but would be claiming some kind
of priority over other methods. The authentication record at _AUTH.<ID>
could still specify SPF or whatever method the ID owner wants.
Given that the intent of the ID command is neutrality, I doubt anyone will
get far with insisting it have any semantics relating to one method. Let's
keep an eye on SUBMITTER and see how far the PRA advocates can push it
through the IESG without backing off on their PRA-only semantics.
> As I understand it, the HELO identity is supposed to be the
> hostname of the sending MTA.
Exactly.
> That is not the best place to accumulate
> reputation,
What better place to check the reputation of the sending MTA than at the
identity which is supposed to be the hostname of the sending MTA? Your ID,
otoh, can be anything (presumably a domain name); and because it can be
anything, it is nothing. Unless you do SPF checks on it -- in which case
you can already gather everything you need at HELO or MAIL FROM.
A better place to accumulate reputation is at the top level of an
administrative domain. The reputation services will prefer not to track
individual hostnames, and the owner of a reputable domain will prefer to
have a large flow of legitimate mail, so he doesn't get cut off when just a
few spams sneak past his outgoing filter.
The problem with CSV, as I see it, is that by putting all the
authentication records at the lowest level (each and every sending MTA),
they make caching of those records much less effective. Typically you will
need one query per transfer. They make a big point how much better that is
than the worst-case SPF setup, but they don't understand that SPF can be
much better if set up properly. A large domain like rr.com could activate
the SPF record they already have, and have their entire domain protected
with one record. Caching that record will be very effective, reducing the
number of queries to the server to maybe 1 per 100 transfers. So I see CSV
as avoiding the worst case 100:1, but not taking advantage of the best case
1:100 that is possible with SPF.
--
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 *
************************************************************ *