Re: [anti-spam-wg@localhost] Anti-spam WG draft minutes RIPE 46

[Markus Stumpf <]

Thanks for the scribe.

On Fri, Sep 05, 2003 at 09:23:44AM +0100, Rodney Tillotson wrote:
> This is an area which we need to raise with the Database WG.
> [note from the Chair after the meeting: I have brought it to
> their attention and they ask that we present our concerns and
> suggestions for consideration. We will generate a proposal on
> the mailing list.]

I'd propose an (incompatible) change to the whois server:
do not send "changed:" records unless a special option is given.
Neither on inetnum, route or person objects. As every changed: record
contains an email address clueless people/programs go for that. We often
receive complaints to addresses that are listed in changed: records of
persons that are admin-c or tech-c for abused hosts (and some records
date back to 1996 and are no longer under our control anyway).

I'd propose to add abuse-c: records for inetnum and route objects.
For ease of parsing, access speed and to reduce server load (reolving
linked objects) on the whois servers I think it is enough to not have a
abuse-c object but simply a record listing an email address.

Currently this info is often listed with remarks or trouble records as in

remarks:      please send complaints about all network abuse to
remarks:      >>> abuse@localhost <<<

remarks:      *******************************************************
remarks:      * Please send abuse reports to abuse@localhost  *
remarks:      *******************************************************

remarks:      ************************************************************
remarks:      * ABUSE CONTACT: abuse@localhost IN CASE OF HACK ATTACKS, *
remarks:      * ILLEGAL ACTIVITY, VIOLATION, SCANS, PROBES, SPAM, ETC.  *
remarks:      ************************************************************

trouble:      For security related problems contact:
trouble:      -    security@localhost
trouble:      For problems relating electronic mail abuse contact:
trouble:      -    spam@localhost
trouble:      For problems relating dns servers  contact:
trouble:      -    redip_servicios@localhost
trouble:      - Port scanning related problems:
trouble:      -    scan@localhost

I don't think we need 5 or 6 different fields like above. Sorting the
mails out shouldn't be too hard on the receiver side.

> Some discussion followed in private after the meeting. Broadly,
> bulk mailers have noticed that defences against UBE are often
> implemented on the main MX destination and overlooked on the
> rest.

The main problem IMHO is that most backup MX servers /have/ to accept
anything for the domain they host backup MX for, as they don't have
information about the userbase. So contacting backup MX servers spammers
get the email delivered the first place.

> A countermeasure sometimes thought helpful is to add a further MX
> record of lower priority than any real one, which points back to
> the same mailer as the preferred MX.

We've tried this with a few customers and our observation was that it
didn't help at all. At least not with setups like
     MX   50 mail.best.example.com
     MX  100 mail.backup.example.com
     MX  150 mail.best.example.com
i.e. if shortest and fastest distance MX records carry the same name.
However I don't know if different names really would make a difference.

> in general, alternative MX systems
> should have security configuration to match the main mailer,
> though they may be of smaller capacity.

Usually - at least as an ISP - you can't enforce same policies for the
backup MX as the customers do for their best MX. A simple example are DNSBLs.
You can't setup blocking DNSBLs on a backup MX server unless all customers
agree, which is unlikely to happen.

IMHO this is also the biggest design problem with
    AMTP - Authenticated Mail Transfer Protocol
        http://www.ietf.org/internet-drafts/draft-weinman-amtp-00.txt
    4.2.3 Mail Policy Code (MPC)
(which was featured as a revolutionary anti spam strategy this week by a
german IT news service:
    http://www.heise.de/newsticker/data/uma-02.09.03-000/
reference for german readers ;-)

The MPC handshake takes place before and independently of any RCPT TO
commands. So as an ISP, hosting emails on some servers for some 1000
domains and users, our mailservers have no way to implement per customer MPC.
In fact even per customer MPC isn't satisfying, was large email hosters
(hotmail, yahoo, ...) may want to allow their users to specify MPCs.
So AMTP is broken by design with regard to MPC and for the rest: this
can easily be done right now with stunnel and a small wrapper.

> It is even questionable
> whether you should operate an alternative MX destination for an
> end-point mail system; it will be necessary for large user
> communities and for transit mailers, but for others the cost and
> complexity may be more than the expected benefit.

I can't imagine any reason why someone would need to have a backup MX
these days. It was most useful years back when leased lines were
expensive and congested and the goal was to bring the mail at least closer
to the destination and to cheaper and faster lines. It was also helpful
to help mailservers meet that were behind flaky lines and the
probability to have both of the up at the same time was low.
Today, if a mailserver is down, you either have a standby system to
take over or you have a load balancer and a cluster. In neither case you
need backup MX servers.
There is no benefit in spooling all emails from around the world to a server
that can't deliver them to the final destination anyway and only fills up his
queues. IMHO it's better to have the queue distributed over a few hundred
servers ;-)

	\Maex

-- 
SpaceNet AG            | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development |       D-80807 Muenchen    | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
 proportional to the amount of vacuity between the ears of the admin"