At 07:54 -0400 on 06/29/2005, John C Klensin wrote about Re:
Bounce/System Notification Address Verification:
--On Wednesday, 29 June, 2005 00:50 -0400 Keith Moore
<moore(_at_)cs(_dot_)utk(_dot_)edu> wrote:
I am not rejecting anything. All I am suggesting is that when
more than one recipient is to be used for the message, to
generate a separate copy for each recipient (with only that
recipient listed as the "To") so there are separate copies
(as would occur with multi-recipient [messages where each
recipient is in a different domain] at the MTA stage ).
Why should an MTA or MUA bother to do this? This part of the
SMTP standard has been stable since c. 1980 and it has _never_
required this.
...
spammers have consistently shown themselves to be very
flexible at adapting to far more substantial countermeasures.
and it's much easier for spammers to adapt than for the vast
installed base to adapt. it is counterproductive to impose
meaningless restrictions on legitimate senders. in the long
term this only adds complexity and damages transparency of the
mail system without doing anything to discourage spam.
And, of course, going to one-recipient-per-message also vastly
increases total transmission time for messages, especially
moderately long messages, in normal use. That total
transmission time issue -- let's open a minimal number of TCP
connections and transmit the payload on a target host basis, not
a target user one-- is, of course, why the multiple RCPT
provision was included in the mail specs more than a quarter of
a century ago.
Since it is my comment being quoted, I'll respond. My suggestion is
ONLY about Mail-From <> messages. These messages are (so far as I can
tell) very short Payloads (under 1-2K) and since they will all be
queued at the same time will flow back-to-back over the same
MTA-to-MTA session (ie: No extra TCP/IP Setup/Teardown overhead).
What automatic <> replies that support multiple recipients do you
expect to exceed my 1-2K payload size? The "multiple RCPT
provision" was instituted for a problem that no longer exists (narrow
pipes, long setup/teardown times, and slow transmissions). With the
current speeds/bandwidth the extra traffic gets lost in the noise.