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

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 1 May 2003 07:01:28 -0700

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:	[email-masked]
Subject:	RE: [Asrg] A New Plan for No Spam / Velocity Indicator

> From: "Tom Thomson" <[email-masked]>

> 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    [email-masked]
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 1 May 2003 07:11:13 -0700

Ok forget he said she said

I beleive that mtas should not accept bcc mail except from mailing lists
that advertise as such and close parties.

I dfine a close party as anyone I have exchangd mail with recently, anyone
in verisign.com.

We are talking about making it more expensive for spammers. Stopping them
from using this feature is one of the lowes impact restrictions we can make.

Phill

 -----Original Message-----
From: 	Tom Thomson
Sent:	Thu May 01 03:56:34 2003
To:	[email-masked]
Subject:	RE: [Asrg] A New Plan for No Spam / Velocity Indicator

>Note that contrary that document, it generally makes no sense to talk
>about valid BCC fields in incoming legitimate mail.  See page 37 of
>RFC 2822.  I wouldn't be surprised if SpamAssassin treats a BCC
>header as evidence of evil, because I can't recall ever seeing one
>except in spam.  More important and also contrary to that document,
>RFC 822 and RFC 2822 do *NOT* require that every incoming message name
>the receipient in any SMTP header.  Most legitimate mailing list
>messags are cases in point.

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.
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.

>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.

Tom

---

From: "Eric D. Williams" <[email-masked]>
Date: Fri, 2 May 2003 11:20:36 -0400

On Thursday, May 01, 2003 10:01 AM, Hallam-Baker, Phillip 
[SMTP:[email-masked]] wrote:
8<...>8
>...I would no more expect to be able to know the smtp spec from the rfcs
8<...>8

I am not sure what you mean here.

The 'specification' as an RFC is a basis document not a Bible. 
 Interoperability is completely separate from protocol conformance, e.g. C 
works with A but not with B, all are compliant with the 'specifications' when 
tested against the reference implementation of the PICS pro forma.  One can 
implement or test an interoperable system based upon the protocol 
specification.  Also, a pro forma protocol implementation conformance criteria 
is what any vendor (or standards body) should use BEFORE rolling out an 
implementation.  That being said, interoperability is not dependent on the 
complete set of described protocol semantics the so-called PICS can be adapted 
by an implementor to concern only the most relevant aspects for 
interoperability in the operational environment, ignoring others and/or 
extending them.

-e