ietf-mxcomp
[Top] [All Lists]

Re: Choice of SMTP headers

2004-03-24 12:15:00

On Wed, Mar 24, 2004 at 12:25:40PM -0600, wayne wrote:

In <158927513(_dot_)20040324071735(_at_)brandenburg(_dot_)com> Dave Crocker 
<dhc(_at_)dcrocker(_dot_)net> writes:

AD>   I can think of a number of new protocols deployed at the edge, and
AD> in wide use, in significantly less than 3 years.

Please name them.

Well, I guess it all depends on your definition of "wide use", but off
the top of my head, I can suggest HTTP, AIM, DNSBLs, and it looks like
SPF is well on the road to widespread use.


HTTP did not see "wide use, in significantly less tha 3 years".
  From http://www.mit.edu/people/mkgray/net/web-growth-summary.html :

In the two year period from 6/93 to 6/95, there were only 23,500
websites.

I can't find any data on the growth of AIM or the OSCAR protocol, but
I'd be very interested in seeing the data on which you've based your
claim.

Similarly, I can't find any historical data on DNSBL use versus number
of deployed MTAs, but I'd imagine Paul Vixie may have such for MAPS.
But MAPS started as a private list, distributed via BGP.  It was started
in 1997, and there were rulesets that could be manually added to
sendmail.cf late that year, but whether it saw "widespread use"
significantly before 2000 is an open question.  Certainly, sendmail 8.9
had MAPS use as a feature, but that wasn't until mid-1998.  And
inclusion of a capability does not connote use, unless that feature's
turned on by default.  It wasn't.

As for SPF on the road to widespread use:  Isn't the current registry at
only about 6000 or so domains?  Out of an estimated 250,000,000 (source:
http://www.isc.org/index.pl?/ops/ds/ ).  Even if there were 6 million
domains advertising SPF records, it wouldn't we "widespread use".
Further, "use" would include the number of MTAs performing SPF checks.
Sure, the number will spike a bit when the version of SpamAssassin that
includes SPF scoring is released, but that's like saying that the #6
Torx screw is hugely popular with consumers based on their consumption
of microwaves.  The consumers must really love that screw.


Right now, the burden of unauthorized usage of domain names falls
largely on the domain name owners.


And right now, that burden is a bit difficult to bear in mobile
scenarios, without very short zone TTLs and some means to dynamically
update the records remotely and securely.  Some may argue the latter's
easy for a notebook, and I might agree.  But notebooks aren't the only
mobile devices that use SMTP.



Actually, the LMAP proposals all allow the domain owner to track the
DNS lookups, so that they can get a general idea of the variety of
access venues.  SPF allows for much more detailed tracking and for the
DNS lookups to be directed to a different nameserver so that the
logging is much more practical.

This means that the domain name owner can have a much better idea of
of the variety of access venues than any individual end-user.



Actually, it means the domain name _administrator_ can have that idea.
Bear in mind that "domain name owner" and "entity responsible for zone
changes, tracking such statistics, etc." are often two very different
people.  The owner may well want to use SPF, but be unable to because
the entity administering the domain does not have knowledge of SPF, the
tools with which to manage use of SPF, or the willingness to change the
zone in the manner requested once, let alone on an on-demand basis.


AD>   And if end-users wish to use an MTA not listed in DNS for a domain,
AD> they can talk to the domain owner.

That is the same as saying that the end-user carries the burden.  This
is about end-user impact, not the act of text editing domain records.

If the end-user has no legal right to use the domain name, then
denying them the use of that domain name is not a "burden".  Stores
that install anti-shoplifting devices are not placing a "burden" on
shoplifters, even though shoplifters may no longer be able to shoplift.


If the end-user DOES have a legal right to use the domain name, and they
are prohibted from doing so thanks to SPF or similar proposals, what
then?


AD>   That is, SPF allows end-users to register MTA's.  It doesn't
AD> "require" that registration.

Right.  And end-users are not "required" to send email.

End users are not required to send email from domains that have not
approved of their use.  With domain name ownership going for
$5-$10/yr, it is likely that end-users will be easily able to find a
domain name that they can reasonably use.


Again, what about the legitimate use of a domain name, prohibited
because the end-user doesn't happen to be sitting behind a "blessed"
machine at the moment, or is unable to connect to a "blessed" MX?



The LMAP proposals are, fundementally, about giving domain name owners
a voice.  The fact that some domain owners will choose to say things
that are shortsighted, bad, hateful, or stupid is not a valid reason
keep them gagged.  

Okay, then:  This domain name owner would like to use his voice to state
that he's not happy with the idea of being unable to use his domain
names while mobile.  Bear in mind that the addition of hoops that must
be jumped through while mobile will not win me over, because one of my
uses is via cellphone -- a device that's not very flexible when someone
points to it and says, "just make it jump through these additional
hoops..."


I've always operated on a "send from lots of various places under a
single identity" principle.  Home, work, coffeeshops, in the park, at a
hotel, in an airport, at a friend's house.  From my laptop, other
people's laptops, public terminals, PDAs, cellphones with MUAs built-in,
cellphones acting as modems, and so forth.

I can see merit in the argument that begins, "a client could be written
to dynamically update the TXT record when you connect to the network",
were we discussing a notebook I own, on a network with no transparent
proxies.  But that's not the case.

-- 
Mark C. Langston                                    Sr. Unix SysAdmin
mark(_at_)bitshift(_dot_)org                                       
mark(_at_)seti(_dot_)org
Systems & Network Admin                                SETI Institute
http://bitshift.org                               http://www.seti.org


<Prev in Thread] Current Thread [Next in Thread>