ietf-asrg
[Top] [All Lists]

RE: [Asrg] A New Plan for No Spam / Velocity Indicator

2003-05-01 06:29:36
From: "Tom Thomson" <tthomson(_at_)neosinteractive(_dot_)com>

Phill's document already points out that mailing lists are an exception
which require exceptional treatment, so your "case in point" appears to be
vacuous padding to try to fool us into thinking your message has more
substance than it has.

He did not say that mailing list software should be changed, but in
effect said that all major past and current SMTP mailing list software
violates words in RFC 822 that do not exist.  In fact RFC 2822 not
only does not require that recipients be listed, but allows an MTA to
remove BCCs.  He probably made the mistake common among end users who
complain about spam not containing their addresses, because they do
not know about or understand the significance of the SMTP envelope.
If you have not spent much time fighting spam or SMTP servers in more
than their external configuration spam, it is easy to not know about
the SMTP envelope.


As for the bcc case, I used to use an MUA which generated n+1 copies of the
body - 1 for each bcc recipient containing a bcc line with only that
recipient, and one for all To and cc recipient containing no bcc line. These
were transmitted separately - multiple Rcpt To lines with one Data phase for
teh To and cc recipients, single Rcpt lines with a data phase for each bcc
recipient. Since Phill is as much of an antique as I am, maybe he too
remembers MUAs which did rather pleasant and intelligent things that didn't
conform to the modern desire for "efficiency" at all costs (even at the cost
of effectiveness) and maybe that's where theerrorneous statement comes from.
An easy mistake to make if you grew up with civilised MUAs.

I still use an MUA whose first version probably predates the MUA that
you are thinking of.  It sends a single copy with the BCC recipients
mentioned only in the envelope.  The only older UNIX MUA that I've used
of also sent only a single copy.  (Email systems I used before UNIX
were too different to mention.)  The MUA that I recall that did as you
describe was a fancy, "extensible," and "user friendly" package offered
as a replacement for those two older MUAs.  I've often wished that my
preferred MUA would do as you describe, because I've learned the hard
way the importance of preceding a BCC'ed message with another that says
something like "the following is a BCC so don't reply to all."


What discourages me most about this mailing list are self-described
expert statements such as "the RFC822 message standard requires every
message to have a valid To: CC: or BCC: field identifying the recipient,
making adjustment where necessary to account for messages relayed
through mailing lists."  There are obvious reasons why RFC 822 and
RFC 2822 do not require mailing list exploders to anything of the sort.

Heavy protestations of knowledg and expertise which are clearly false bother
me too, but I also know the story about the pot and the kettle.

Are you sure you see all of the relevant applications of the pot and
kettle story?  Do you see some of the obvious reasons why RFC 822,
RFC 821, RFC 2822, and RFC 2821 do not contain the words that the
other person thought they do?  Did you check RFC 2822 on BCC headers?

Requiring that every message list the recipient in a To, CC, or BCC
header would require that the MTA serving the MUA that is the mailing
list exploder send each copy to the next hop MTA by a separate SMTP
transaction.  The exploder MUA might do as it does now, sending messages
to its MTA, each addressed to from 10, 100s, or perhaps 1000s of
targets, but unlike now, the MUA would add to message BCC headers for
each addressee in the batch.  To honor the blindness required of a
BCC (and the "Security Considerations" in RFC 2822), the MTA must
convert those individual batch messages into sparate messages.  Each
new message would contain a single BCC header mentioning a single
addressee, and would be handled in a separate SMTP transaction.
Alternatively, the exploder MUA could generate the separate messages,
each with a single BCC header.

Have you watched an SMTP client responsible for passing a modest (few
1000 subscribers) or larger mailing list, particularly on hardware
and networks more than 10 years old?   Mailing list subscribers have
always tended to be clustered on SMTP servers, even before big ISPs
like AOL.  Requiring separate transactions for each addressee would
increase the load on the system by 10 times.  I suspect that is why
sendmail at least as early as the mid-1980s was willing to sort by
next-hop and use a single SMTP transaction when possible.


Vernon Schryver    vjs(_at_)rhyolite(_dot_)com
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg