Anti-spam measures

> >   > 
> >   > One of the best things to do, would probably be to make a simple turnkey
> >   > kind of sendmail config available to people.
> >   
> >   	What I think as the best solution is to patch sendmail
> >   	to check from the name service if we really are in the
> >   	mx list for the incoming mail. This would eliminate
> >   	the need to store the same information to some other
> >   	place, as we already have the information stored in
> >   	the name service.
> 
> The idea is good indeed. I am, however, somewhat concerned about
> the following potential dangers:
 
 Here are some of my personal thoughts on spam problem and one idea on
 how to deal with it. I've had these for quite some time, but somehow
 was unsure about applicability, and actually still isn't.
 Maybe you'll find it interesting, or find it unusable pretty fast. 
 Anyway, I'd like to hear any comments.



 Spam will not be gone until it is either impossible or technically much
 too troublesome.
 Legal regulations don't work and won't until most of the world follows this.
 What might worry ISP-s is that when actually major fake-mail case will pop
 up, causing some party major losses due to maliceous intent, lawyers would
 ask ISP's what have they done to restrict fake-mail possibility?
 Long before such case it can be easy to keep an URL on a web page stating
 that email is not secure, but when someone gets really bitten, they would
 claim its not enough. You SHOULD do something about it. And currently there
 is almost nothing you can do. Some SMTP mail software have to be modified,
 some RFC-s be written, followed and enforced.
 Who would do that? Whatever we might wish, fake mail and spam will not be
 gone until it is taken under the control. Who else should start the process
 if not the ISP-s who are the major cause of the damn trouble and the most
 victims?

 Spamming methods.

 1) spam is anonymous fake email with fake headers almost always.
 2) spam is injected to open relays with no authentication whatsoever.
 3) site whose domain the spam is faking usually does not permit spamming,
    but has no control over its domain being used by spammers.

 Possible solution:

 1) mail Sender is accepted ONLY from an IP address, that is on the list of
    MX hosts for the sender's domain. Relay on DNS authority. DNS fakings
    is probably solvable temporary problem.

  This:
   a) Rejects non-existing domain senders, configuration errors.
   b) Rejects mail from relays that are used for injecting unauthenticated
      email sender.
   c) Brakes happyness of those people, who love to use single email address
      but injects mail wherever they can... This is wrong behaviour in the
      first place, and could be fixed by 3)

 2) Mail Recipient is accepted ONLY for domain, which is on the MX list
    with receiver SMTP server, AND is allowed to be relayed.

 3) EMail can be injected into SMTP world only via pop3 or similar, after
    authenicating senders username/password.
    Envelope-senders return-path would be out of control of luser and
    ideally always correct.

    As dialin PC-s usually don't have MX, they would not be allowed to
    inject mail via SMTP server, but only via pop3 or similar. Or, ISP
    that hosts those dialins could define an MX for its mailserver,
    making it possible to its user population to inject mail via his
    mail server only and thus make slow transition.

    It would be needed to add POST method to pop3 or any other
    authenticated mail protocol widely used. This is the most problem with
    this scheme, but could be solved if principally accepted.

 End result:
 1) End-users ideally would not be able to inject email into SMTP world
    otherwise than by authenticating themselves to their home-server.

 2) SMTP world operates only with mail messages that are expected to be
    authenticated by some mail server. Without authentication, users
    cannot inject mail altogether, thus closed accounts are really cut off.

 3) SMTP world relays mail only from valid MX-list to valid MX-list,
    anything that violates this is rejected. Control over originating
    sender hosts is given to remote domain DNS administration, control over
    relaying is given to local DNS administration.

    It is possible to ensure that no single mail message is faked within
    a community of SMTP servers implementing this. (IMHO)

 4) SMTP servers that do not follow this continue to operate for their
    valid MX-ed domains, but are unable to deliver "fake" mail to those
    that do follow this scheme. Eventually this would force to take
    measures for all sites.

 5) the more SMTP server become so strict, the less spam is left around.

 6) SMTP servers that follow this scheme, but relay spam, are subject
    to RBL, blacklists or other means of Internet enforcement.



 ----------------------------------------------------------------------
  Andres Kroonmaa                                mail: andre at online.ee
  Network Manager
  Organization:            MicroLink Online       Tel:        6308 909
  Tallinn, Sakala 19                              Pho:  +372  6308 909
  Estonia, EE0001        http://www.online.ee     Fax:  +372  6308 901
 ----------------------------------------------------------------------