North American Network Operators Group
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Paul's Mailfrom (Was: IETF SMTP Working GroupProposal at smtpng.org)

  • From: Brad Knowles
  • Date: Tue Aug 27 19:10:43 2002 
At 12:16 PM +0200 2002/08/27, Bruce Campbell wrote:


 I understand the proposal to be based on the envelope sender, not the
 sender in the body.  Hence, mailing lists work, because they are the
 envelope sender, not the person who submitted the mail to the mailing
 list.
Read my previous comment about mailing lists that do not change the envelope sender (e.g., mailing lists that are instead run as simple aliases).

 Pardon?  Are you saying that for a given entity (say, example.com), your
 administrative procedures are such that you do not know all the machines
 that can send email directly to that part of the Internet outside that
 entity?
Not if example.com is a vanity domain and is not allowed to transmit mail directly to the outside world, or actively chooses to use the relay services provided by their ISP. You may know the entry point, but it can be difficult to determine all the possible exit points.

 Even for an entity like aol.com, their outbound mail servers appear to be
 a small(ish) set of circa 20 machines which can be listed appropriately by
 AOL.
I know. I set those machines up. They haven't really changed much since I left in '97. But try listing 20 different names as MXes for a mail-from label. Have you heard of this thing called "DNS response truncation"? Do you know the kinds of problems it causes for many MTAs, even today?

 Yes, entirely correct.  However, the bulk of the Internet mail today is
 from one host to another host.  Knowledge of the path the mail takes, on
 the SMTP level, is not needed by the mailer, unlike UUCP which required
 the mailer to be aware of various routing topologies.
It is if you have to know all the possible exit points for e-mail that you may transmit.

 The rest of your mail is an invitation to clean up the little bit of
 forward and reverse domain space that is under your immediate control,
 which is a Good Thing IMO.
Indeed, it would be good to get this cleaned up. But let's be realistic. When you have 256 total gTLDs and ccTLDs (plus the root zone), served by 762 unique machines, and 413 of those machines are open public/recursive nameservers in addition to their authoritative duties, leaving everyone underneath 204 TLDs susceptible to attack via cache poisoning at one or more servers for their TLD, you realize that there are much more serious problems that have to be solved.

--
Brad Knowles, <[email protected]>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
-Benjamin Franklin, Historical Review of Pennsylvania.

GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E W+++(--) N+ !w---
O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++)
tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)