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

On 2003-04-27 20:20:55 -0700, J C Lawrence wrote:
> On Sun, 27 Apr 2003 16:41:15 -0700 
> Phillip Hallam-Baker <Hallam-Baker> wrote:
>
> > I don't see the validity of the argument.  The problem is mta
> > filtering, so the mua issue is moot. If the message gets to the mua
> > this problem is solved.
> I disagree rather explicitly.
>
> Spam is an inherently subjective definition that can easily be
> subjective to and specific to a particular message.  More simply in
> defining consent, it is the user of the MUA who defines, communicates
> and arbitrarily waives or enforces his consent rules, not the MTA.
I agree with that.

> These aspects convince me that consent definition and enforcement has to
> occur at the MUA level.  Its the closet point to that fickle and
> technology-ignorant luddite human. 
One problem with those fickle and technology-ignorant luddite humans is
of course that they don't want to be bothered with "technical details"
like defining rules and expressing consent. They don't want to see any
spam (not even in a special Junk folder, if at all possible), they don't
want to lose any legitimate mail, and they expect that to "just work"
automatically. The ISP (or IT department) should (possibly using a
crystal ball or telepathy) filter out exactly the unwanted mails. 

Ok, that might be a bit exaggerated, but I think any mechanism which is
visible to the end user must be extremely simple. If they have to click
on a button once every hundred mails or so to inform "the computer" that
it has made a mistake, that's ok. Anything more complicated (like
deciding whether you want to whitelist an individual or a mailing-list,
or which BLs or SpamAssassin rules should be used) or work (like
C/R-systems) will probably be ignored.

(We will probably upgrade our users to Mozilla 1.4 when the final is
released, I am curious whether users will use the bayesian filters)

> 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.
>
> > Equaly people who upgrade their mta filters are going to upgrade their
> > mta if that is required.
> 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.
>
> 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. 

However, I think rejecting unwanted messages immediately (instead of
accepting them and later generating a bounce or silently dropping them)
is preferrable for two reasons:

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

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.

So the MTA should be able to check the consent token. This is certainly
possible even if it is contained in the message headers, as a message
can still be rejected at the end of the data phase. It "only" causes
additional traffic (not much, AFAICS: Most spams are short, and proxies
often send the whole smtp transaction without checking for 5xx replies).
The way the MUA can communicate with MTA to tell it which consent tokens
are valid and which aren't is a different (and non-trivial) problem, of
course.

        hp


-- 
   _  | Peter J. Holzer    | Latein ist das humanoide Äquivalent
|_|_) | Sysadmin WSR       | zu Fortran.
| |   | hjp(_at_)hjp(_dot_)at         |
__/   | http://www.hjp.at/ |    -- Alexander Bartolich in at.linux

pgp77QnNXZ7by.pgp
Description: PGP signature