Re: Getting open smtp servers fixed

[Herman Van Uytven <]

If I would be a spammer, I would easily get around the 3 points below.
But a variant of point 3 (see below) can probably help much.
>Solution (b) is probably the most promising.  There are a set of well
>known filters that can be used, such as:
>
>1) If the "Received" sequence does not make sense (did not follow MX
>records) the message is suspicious.
>
>2) if the message comes from a mailing list (which can be detected by
>looking at the RFC-822 and SMTP From fields, and also by the Received
>sequence), the user should have explicitly subscribed to the list.
>
>3) if the message comes from an "unusual" sender (someone from which the
>user has not received mail before), check for key words such as "free sex"
There you got a point.  Do not receive mail from a "new" correspondent.
The problem is when two new correspondents want to start talking
to each other.  A will block B, and B will block A.
So what is needed, is that when A mails to B, B should be added
directly to the list of valid correspondents of A, since B will
probably send a 'challenge' to A to get in the valid recipient list
of B.
That's why you need mailers connected to real databases (and not
to static and large dbm files which can't be rebuild during each mail).

Systems to block "new" coorespondents
exists already, but they are not usable for 'simple'
users since it requires the maintenance of some file used by procmail,
and simple user nowadays can't update a text file anymore, or simply
will always forget to do a registration before mailing to someone new.
In our case we do not even allow telnet access to the mail servers.

So the process to register someone as a valid correspondent should
be made as simple as possible, and where possible the process should
work automatically.

I would suggest:

- when A mails to B, B gets automatically added to the valid correspondent
  list of A.  + extra futures if B is listserv or majordomo or mailbase.
- the valid correspondent list should be integrated with the address book
  (web based).

So you need:
- integration of mailers and databases
- to make it easier for end users: do everything via the web
  (address book is web based and integrated with valid correspondent
  list, the challenge will probably go via a web registration, so
  it would be a mess if other things (= reading/sending mail) would
  go via a separate program.

It's not an easy way, since you need to couple mailers to databases
and write web interfaces for some things, but if there would be
an easy solution the spam problem would have been solved already.

A scenario when A tries to mail to B:
1) A mails to B
2) mailer of A adds B to valid correspondent list of A
3) mailer of B refuses mail of A, because A is not in the valid recipient
   list of B.  A receives an error mail pointing to an URL of B.
4) A goes to the URL of B.  A needs to give his E-mail address in
   the web form of B.
5) the web form of B mails a challenge (a random generated number) to A.
6) A receives it and registers it in B.
7) A will be added to the valid correspondent list of B.
8) A and B can exchange mail.

The challenge mechanism must be different for each site or person,
so that it can't be answered automatically.

In step 2 the mailer of A should catch commands to listserv, majordomo
and mailbase or typical list address (list-request, ...),
scan it for subscribe commands, and add the listname
addresses and mailing list manager addresses to
the valid correspondent list of A.

-Herman-
>
>Don't we have someone here that could write a sendmail extension that
>would do exactly that?
>
>--
>Christian Huitema