Actually I find it rather difficult to accept the terms 'design' and smtp in
the same sentence without a negative inbetween.
Interpretation of ietf docments of the era are at best an exercise in
hermeneutics. I use the term advisedly since there is much that is not
written that is as important as that which is.
Do not ascribe to ignorance of others what may be due to your own lack of
knowledge. In this environment that type of talk is far more insulting than
anything else which may be said.
Rfc822 is a deeply flawed document. It was written in an ra when we did not
know better and it was writen in an era when rfc meant what it says. Rfcs
began not as standards but as the starting point for standards. But even so
it does not state that the to cc etc addresses mean other than what one
would assume them to mean.
My position is quite clear, he definitin of smtp is embedded in internet
usage. I would no more expect to be able to know the smtp spec from the rfcs
than I would expect to understand theology from reading the bible alone.
-----Original Message-----
From: Vernon Schryver
Sent: Thu May 01 06:30:59 2003
To: asrg(_at_)ietf(_dot_)org
Subject: RE: [Asrg] A New Plan for No Spam / Velocity Indicator
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
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg