Subject: RE: [Asrg] Lets Fix Mailing Lists

From: "Tom Thomson" <[email-masked]>
Date: Tue, 11 Mar 2003 13:17:30 -0000

Henrik Levkowetz <[email-masked]> wrote:
On 9 Mar 2003 02:41:20 "Mark Delany" <[email-masked]> wrote:
<snip>
> The one down side is that all mailing lists have to send individual
> mails to each recipient and we all know what sort of red flag that is
> to some bulls.

That sounds as if you think the confirmation token needs to be handled at
RFC2822 level rather than at RFC2821 level.  Since the mailbox to which the
message is to be delivered is identified only at RFC2821 level, that seems a
little odd to say the least. Surely the token should be handled at the
envelope level, just as a matter of principal (the tokken expresses consent
relating to an envelope - RCPT_TO - destination, not to anything specified
in the content, in the context of the envelope sender (mailing list) not in
respect to anything specified in the content).  And putting it at the level
it belongs at would avoid waving that red flag to those bulls.

As well as elimintatinmg the red flag, putting the token in the appropriate
level of protocl eliminates another problem that would arrive from putting
it in the wrong place.  Email sent through RFC821 systems does not have to
conform to RFC2822 (see first two paragraphs of section 2.1 of that RFC,
which list some mail content RFCs which use octets not permitted in RFC2822
conformant mail).  There is no requirement on MTAs to understand RFC2822 or
any other standard that might be used to encode a mail body - they only have
to understand RFC2821.  I think that the volume of RFC2822 non-conformant
email is now greater than the body of RFC2822 conformant email  (it
certainly is in terms of mail I receive, one reason being that a lot of it
uses the ISO western European character set rather than USASCII). So putting
the solution in a replacement for RFC2822 instead of in a replacement for
RFC2821 will just not work for most mail transferred through RFC2821
conformant MTAs unless we put it also into every other content encoding
standard (and it would require MTAs to have to mess about in stuff that is
essentially none of their business).

Tom Thomson

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "Mark Delany" <[email-masked]>
Date: 11 Mar 2003 17:57:45 +0000

On Tue, Mar 11, 2003 at 01:17:30PM -0000, Tom Thomson allegedly wrote:
> RFC2822 level rather than at RFC2821 level.

Someone else said much the same thing. I agree with you both that
having it as a "rcpt-parameter" is more optimal than embedding it in a
header. I have no particular attachment to either method as the
purpose here is to demonstrate our incredible inertia even in the face
of obvious and simple ideas.

This particular idea requires no more than a private token database
along with a bit of protocol support and we instantly eliminate the
need for all bulk whitelist management systems and henceforth have
unequivocal proof of opt-in by the subscriber. Yet we've let the
absence of such a mechanism plague us for over a decade! Depressing.

Btw, the idea trivially extends to person-to-person email too.  With
the same sort of "relationship proving token exchange" you instantly
and reliably corner spammers into what I call the "introduction
problem".

The beauty of the "introduction problem" is that, in the absence of
getting a token from their victims - something most victims won't do,
spammers are forced to re-introduce themselves to their millions of
victims each and every day.

The fact the spammers confront the "introduction problem" millions of
times each day is an unavoidable, many-orders-of-magnitude
differentiator that we can take advantage of, if we can overcome our
inertia.

Regards.