Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)

Tue Aug 27 21:51:43 UTC 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, <brad.knowles at skynet.be>

"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(+++)