ietf-asrg
[Top] [All Lists]

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

2003-04-28 11:54:40
On Mon, 28 Apr 2003 20:30:09 +0200 
Peter J Holzer <hjp-asrg(_at_)hjp(_dot_)at> wrote:

On 2003-04-27 20:20:55 -0700, J C Lawrence wrote:

Certainly the rules etc can be communicated up to the upstream MTA
for efficiency, but that's not actually required for correct
operation -- its just an attractive option.  =20 > Equaly people who
upgrade their mta filters are going to upgrade their > mta if that is
required.  =20 My current thoughts lead me to classify end users into
two camps: Those that can natively support a formalised consent
definition, and those that can't.  As that choice, as above, is to be
made at the MUA level, the only requirement of the MTA then is that
it be configured such that the consent expression "payload" (for want
of a better term) can actually get thru and reach the end user's MUA
for appropriate processing.  =20 I've been beating on this particular
point for weeks, and the only reliable transport I can come up with
is variants of plus addressing, but I'll post more on this soon as I
finish scraping time together for a consent token protocol proposal
which is layered atop SMTP and RFC 2822 without violating either.

If it has to get to the MUA, I don't think it is necessary or even
desirable to make the "consent expression payload" explicit in the
SMTP dialog. There could be an email header (e.g., Consent-Token:),
which the MUA can check before presenting the mail to the user. No
change to existing SMTP servers is necessary since they (usually)
don't throw away any unknown header lines in the messages they
transport. OTOH, plus-addresses are frequently mangled by forwarding
or alias handling.

Encoding consent tokens in additional headers has a fairly simple
problem replies to sent messages will (almost guaranteed) not carry the
consent token.

  Bubba emails Boffo for help.

  Boffo replies.

  Bubba should receive Boffo's mail as de-facto consensual.

Ditto for transits across .forwards, aliases, mailing lists and courtesy
copies.  There are ways around this, for instance by encoding consent
tokens into Message-IDs and then looking for them in In-Reply-To and
References: headers, but this of course breaks for those MUAs that don't
generate In-Reply-To: or References: headers...

Next this doesn't at all address the issue of email relationships
established outside of SMTP, such as an email address entered on a web
form in the, "Please send me more information!" field, or even mailing
list subscriptions.

1) If I send somebody mail, I want to be notified if there is a
problem.0 Therefore, I think silently dropping mail is bad.

There a great tendency to attempt to view the spam scene in terms of
rights and expectations.  What rights and expectations does a sender
have?  What rights and expectations does a recipient have?  What are the
guarantees?

Doesn't make sense to me.  Quite obviously senders are going to send
anything they damn well please; they have a wire and an urge to drop TCP
packets into it.  Equally obviously recipients are going to filter; they
have a wire and an urge to stem the flood of packets.  Senders may
cooperate with recipients in order to help get their packets thru, but
they have no obligation to.  Conversely, recipients have every
motivation and necessity to make their filtering mechanisms, of whatever
draconian and arbitrary form, as effective and annoyance removing for
themselves as possible.  This is pretty standard Darwinian stuff.

2) Because of forged sender addresses, bounces for spam are often not
deliverable, so the spam ends up as double bounces in the postmaster's
mailbox.

I've found that many (most?) sites are configured to silently drop
double bounces.  Too noisy and not worth anybodies time.

-- 
J C Lawrence                
---------(*)                Satan, oscillate my metallic sonatas. 
claw(_at_)kanga(_dot_)nu               He lived as a devil, eh?           
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg