From: waltdnes(_at_)waltdnes(_dot_)org
...
1) Inbound relays is a design decision. It will have to change in
future.
Please say why the reasons that required inbound relays are no longer valid.
...
3) aliases. See 2), the ISP should translate the 550 error message to
a bounce message *TO THE ACCOUNT THAT SENT THE ORIGINAL EMAIL*.
You seem to be thinking of aliases at the source of the mail, while I
suspect that the other person is thinking of aliases at the destination.
4) .forwards The risks of running a bot.
What do "bots" have to do with idea behind .forward files?
Have you never changed employers or had other reasons to want your
own mail forwarded from an old address to a new address?
Would you prohibit ISPs from forwarding mail for recently departed
customers?
...
WRONG. The *MTA* does that. An ISP knows who is logged on via which
IP address. Until such time as the email has been accepted by the
recipient's ISP's MTA, the email is still queued up on the sender's ISP.
They should be able to generate an *INTERNAL* bounce message *TO THE
ACCOUNT (not the address) THAT SENT THE ORIGINAL EMAIL*.
That assumes that the original MTA talks directly to the ultimate MTA
that delivers the message to the final mailbox or at least talks to
other MTAs that do not say "250 ok" to a DATA command until the ultimate
MTA delivers the message. Such a system is not a store-and-forward
mail system. It has advantages compared to store-and-forward, but it
also has major disadvantages. If store-and-forward messaging systems
were not required, we would still be using alternatives such as the
40 year linage that is represented by IRC. (At least 40 years old,
because the Berkeley Project Genie or SDS 940 had something that looked
very much like `talk`.)
...
Removing OOB error signalling is a fundamental protocol change as it
moves SMTP from a largely asynchronous messaging system to a purely
synchronous messaging system.
Main problem is that it's *NOT* OOB. Just ask any innocent victim
who's gotten thousands of bounce messages when a spammer has forged
their email address as the "From:".
Are you sure you understand the same thing in "OOB" that the other
person meant?
.....................
(another msg from someone else)
+ Instead, I would like to see a new and better protocol. The new mail
+ programs could take advantage of it and its new capabilities. (I for one
+ would like to see a References: header just like in NNTP for article
+ threading though that has nothing to do with spam in itself.)
What's wrong with the References header defined in section 3.6.4 of
RFC 2822?
It would be really swell if all of some of these proposals to fix SMTP
were grounded on a little knowledge of the nature of the thing being
fixed.
Note that the author of that particular proposal is not among those
who are really enthusiastic about proposing changes while demonstrating
a distinct lack of familiarity with email and SMTP.
...............
] From: Kee Hinckley <nazgul(_at_)somewhere(_dot_)com>
] >However, I think it would be a bit better if a very few high volume
] >posters such as yourself would start adding either In-Reply-To or
] >References headers just like the vast majority of posters do.
]
] Sure, everyone can just run right out and patch the binary.
Who needs to patch which binaries? I use an older than ancient MUA that
knows nothing about References or In-Reply-To headers. However, except
when I mess up, my messages contain a References haeder, a subject line
identical or strongly related to the preceding article, and are sent
only to the mailing list and not to all of the random other addresses
that have accreted. For me all it takes is some time and effort.
...
] And do most MUAs generate their own Message-IDs?
At least some MUAs leave Message-ID generating to MTAs or MSAs, and
some of MTAs (e.g. qmail in some installations) blow it.
(One of my best filters for bulk mail is the lack of the a Message-ID
line, and the only noticable false positives involve qmail.)
.....................
} From: waltdnes(_at_)waltdnes(_dot_)org
} > More common examples of why relays are required and why they cannot
} > know whether an incoming message can be delivered during the SMTP
} > transaction are MX secondaries and corporate firewalls.
}
} Is the corporate firewall a NAT machine or is it a dumb MTA that
} relays to the "smart MTA" ? If it's a dumb MTA, then why is it being
} used ?
This problem has nothing to do with the intelligence of any MTAs or
network address translation Instead it is related to the practical
problems in synchronizing large databases among computers thousands
of mails apart as well as security issues.
There are security arguments that say that computers exposed to the
Internet should not know anything that is sensitive. Lists of
valid email addresses can be very sensitive. Thus you can reasonably
argue that machines outside your firewalls should not know which
email addresses are valid, and so should not be able to reject
mail to invalid addresses.
In naive, simplistic, and wrong theory, it is trivial to synchronize
databases of 100,000's or 1,000,000's of users names among MX servers.
This is yet another case where "in (naive, simplistic, and wrong)
theory there is no difference between theory and practice but in
practice there is. It is impractical to build a mail system that will
handle all of the incoming mail for a large company or medium sized
ISP but have all of the MX servers have the identical, always completely
accurate list of valid email addresses. You might do that if you
required a business day to turn on email or to terminate an account,
but such a system would be unacceptable today.
} > How can an MX secondary or corporate firewall know not merely that
} > the Rcpt_To address is valid but that there will be no problems
} > putting the message into the mailbox? "User unknown" is not the
} > only 5yz SMTP error code and not the only contents of a bounce.
}
} Then fer-cryin-out-loud, hold off on the "OK" response for a few
} seconds and wait till the email is accepted. If it isn't, issue the
} appropriate 5xx code after DATA:.
I wish I did not think you were seriously proposing that delivery to
the user's mailbox always be synchronous with the SMTP transaction on
your external firewall. It is not only that such a system could not
perform at speed, but that it would have intolerable reliability problems.
Vernon Schryver vjs(_at_)rhyolite(_dot_)com
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg