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

On 2003-04-28 11:54:10 -0700, J C Lawrence wrote:
> On Mon, 28 Apr 2003 20:30:09 +0200 
> Peter J Holzer <hjp-asrg(_at_)hjp(_dot_)at> wrote:
>
> > 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.
I thought it was your idea to modify the MUAs :-)

Seriously:

There are two problems: 

1) If Alice wants to send mail to Bob, she has to include the proof that
    Bob has consented to receiving mail from her in such a way that it
    actually reaches Bob's MUA.

2) If Bob wants to get mail from Alice, he has to send his "invitation"
    to her in a way she can actually use.

Ad 1)

    An additional header will get through almost always, as long as only
    mail transport (.forwards, aliases, mailing lists, ...) is involved.
    As soon as a MUA get's in the way (say the mail is manually
    forwarded) there is a good chance that unknown headers are lost and
    even the known headers are mangled.

    The RCPT TO: address is frequently rewritten at mail gateways. 

    Additional parameters to RCPT TO are not passed on by MTAs that
    don't understand them.

    The To: header is rarely, but sometimes rewritten. More importantly,
    for mailing lists, it usually doesn't contain the address of the
    final recipient, but that of the mailing list.

    The In-Reply-To: header and References are mostly equivalent to some
    new header in terms of "getting through". They have, however, a
    specific meaning - including a reference to an unrelated mail just
    to prove that we had mail contact before seems wrong to me.

Ad 2)

    An additional header will be ignored by any MUA which doesn't
    recognize it. So that requires both Alice and Bob to use a
    MUA which knows about consent tokens.

    A consent token encoded into the From: address will probably end up
    in the To: header and the RCPT of the sent mail. But note that many
    mailing-lists only accept mail from the address you subscribed with.

    A consent token encoded into the Message-Id will probably end up in
    the In-Reply-To or References header (though with lesser
    probability - even on this list there are people with MUAs incapable
    of generating these headers). But only if the mail is a direct reply
    to the mail in question. If the mail starts a new thread, it won't
    include such a header. Similarly, mails to a mailing list don't
    include an In-Reply-To header with the message id of the
    "subscribe" mail.

    A MUA which doesn't know about consent tokens, will of course never
    generate an extra parameter to a RCPT TO command.


In short, I don't think there is any scheme which won't break in at
least some current situations. So I think it will be necessary to 

* use several schemes in parallel

* change some of the infrastructure (over time)

* use the new schemes to whitelist mails, not to blacklist all others
  (because for at least some time, there will be lots of legitimate
  mails which won't comply to any scheme)

> > 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. 
Call them "design goals", not "rights and expectations", then it makes
more sense. We are here to design a system which will dratically reduce or
maybe even stop spam, while preserving email as a useful tool. Stating
what properties of email are useful and hence worth preserving, and
which aren't useful and can be tossed is a necessary step.

To me, having a high probability that the mail was actually delivered
and will eventually be read unless I get a notification is useful. The
use of the bounce system has declined because of spam - today, if I get
neither a bounce nor a reply I don't know if the recipient has read the
mail and doesn't deem a reply necessary or if it was dropped into the
junk folder. But it is still useful, and I think that the reliability of
mail should be enhanced and not lowered by any measures we implement.

> > 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.
I thought about doing this for some time. Occasionally they are useful
however.

        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

pgpysgnQK6s8y.pgp
Description: PGP signature