Postfix anti-antivirus (was Re: [linux-elitists] procmail recipe for mydoom?)

Phil Mayers p.mayers@imperial.ac.uk
Tue Feb 10 17:28:33 PST 2004


On Wed, Feb 11, 2004 at 10:54:48AM +1100, Martin Pool wrote:

> Now the smarthost connects to mx.dest.org, and tries to send the mail.
> The destination sends 550.  So the smarthost generates a nondelivery
> message, and shoots it off to mx.example.com, needlessly annoying
> forged@example.com.

Ah so. Apologies - I couldn't figure out why reject and bounce were
getting confused - they weren't, you're thinking one hop back. My
mistake, I unfairly assumed you weren't getting it - you were, you're
just coming at a different angle, which is cool.


So *I* am supposed to absorb the spam to help forged@example.com. I
believe in teaching a man to fish, personally...

By your argument, I should stand by quietly while people hurl verbal
abuse at me in a crowd, because if they're shouting at me, well, the
other people are not being shouted at, so that makes me a good citizen?

Anyone who knows me will tell you, that is not my style.

(Ok, yes, silly example)

You may be more civic minded than I. In turn, I'm apparently more
optimistic than you that we *can* solve this problem, or at least reduce
it to manageable proportions. My recipe:

1) SPF - so I know the host sending me the mail has a valid, presumably
authenticated return path to the real sender. (If someone is idiot
enough to assert SPF without authenticated SMTP, then more fool them).
This means that the user who *originated the mail* will see the error
code I send, with a very high probability.

2) Content policy - so, lets say someone is sending a researcher at my
site a virus for genuine academic work. They're doing it from an
SPF-enabled site. They will thus see my error message (whereas in your
case, it'd get silently dropped), and can take action e.g. encrypt the
file, put the .doc inside a .zip, change the subject like to make it
look less like spam

The 2 points above make email much closer to a lossless system without
the idiocy of return receipts. That is only a good goal, whereas
silently dropping *anything* has got to be a recipe for reduced
reliability and increased support costs.

So, that solves *my* problem as a destination - for forged source, see
below.

> 
> Depending on the percentage of mail through smarthosts, this could
> double the number of junk messages generated by a particular virus.
> 
> What's worse is that these pointless bounce messages are much harder
> for forged@example.com to filter out, because they don't contain an
> easier identifier like an PE body.

They're relatively easy for forged@example.com to stop, almost totally
- with a couple of bits of infrastructure:

1) spf.rfcignorant.org

(Bad name - not implementing SPF is OK if you don't want to, although
personally I can't imagine why you wouldn't do it. What this DNS list
would tell you is what sites *don't check spf*, as best we know. Easy to
determine via probing. ignorant is not what I mean, but it'd be a
convenient place to put it).

2) Publish SPF

So, mx.example.com sees:

MAIL FROM:<>
RCPT TO:forged@example.com
DATA
Subject: Non-delivery report

Blah blah, we don't check SPF records

.
250 OK

...then, the mailer does:

host -t txt ip3.ip2.ip1.ip0.spf.rfcignorant.org

If this comes up negative, you can trust the remote site is relatively
likely to be doing SPF checks. As such, since you know you're publishing
SPF records for example.com, the NDR should have come regarding a mail
send from one of your outbound MXes in SPF, which means it's as valid
as your smarthost authentication is strong.

If it comes up positive, run the NDR through a SpamAssasin check for
this specific thing (try, for example, to find the message-id in the
mail being NDRed, and check your records for the last 72 hours) and give
it a spam score and act accordingly.

Sites which don't check SPF will find themselves with slightly less
reliable emails, and sites which do check them will find their NDRs are
more trusted and result in a better user perception in terms of silent
loss.

Not perfect I'll grant you. However, sufficient activity generating such
NDRs could result in you being dumped in:

credulous.rfcignorant.org

...i.e. your mailserver is obviously accepting forged From: which
hopefully in a few years time will result in an SMTP-time reject.

> 
> Of course the fault really lies with the client and the smarthost for
> being so stupid as to send viruses.  But they're not under our
> control.  (By all means flame their postmaster or blacklist them --
> that's independant of how the messages are handled.)  What is under
> our control is whether to reject or absorb viruses once they get to
> Destination.
> 
> It is no good to say "people should fix their mailservers".  They
> should, but they won't.  People shouldn't run random executables, or
> dodgy operating systems.  The fact is they do; we need to deal with it
> as it is.

Hmm. If, as computer professionals, we cannot provide a system which is
reasonably safe to use, we're at least partially to blame for the
problems that result. It's no good saying "well, SMTP is just shit and
we have to accept that" (it's true). We should attempt to fix it.

In their current state, giving someone a computer with one of the more
popular operating systems (ahem) on is like giving a random member of
the public a box full of hand grenades and saying "watch that, it's a bit
delicate". Before you know it they've tripped on the pavement and blown
a leg off, and one of the little green eggs is rolling towards you, the
explosive-savvy but sadly human-speed-limited bystander...

We can provide small, incremental and well-thought-out, open-standards
and easy-to-implement upgrades to the global messaging infrastructure
which will return us to a state we can progress from.

Basically - if From: can go back to being trusted or assigned a level of
trust, sites can reliably implement per-domain greylisting, similar to
Karsten's work with per-ASN scoring. We can start to attack the economic
side again - domains are *not* free, and if they have to move domains
once a day to keep sending spam, it's going to cost.

Stamp - pah. That's for the losers who think buying a padded box for the
grenades is the way forward. Me, I like them on a kit vest.

> And (almost) every time, an extra junk message.  Thanks very much.
> Why bother putting in so much effort to clever MAC tracking when
> you're doubling the amount of junk email?

There will inevitably be a changeover period where this causes slightly
more rejection traffic. That should only encourage people to make their
domain Joe Job proof. I'm sorry, I am not willing to put up with the
current level of spam.

My preferred solution gives (or rather - has a good chance of giving):

1) As good protection to a destination as their content filtering,
per-site policy ASN/domain greylisting, antivirus check can give them.

2) Trust back to From: (well, MAIL FROM: actually) which means the
greylisting on domain can actually *work*

3) Based on the domain greylisting, hopefully a reduced volume of spam.

4) It might not immediately address the problem of NDRs for joe jobs,
but the overall effect should be a net reduction in mail noise.
Return-leg SPF checks can confirm an NDR, and greylisting can identify
noisy NDR generators.

However, silently dropping adds no trust to From:, making greylisting
more risky; it increases the lossiness of the email system for everyone,
even between well configured parties who happen just to have different
content policies; and it does not force the clueless to come into the
same millennium as the rest of us.

It's about time people stopped running Sendmail from 1989. "Hey Bob, the
80s called, they want their operating systems back". I have no desire to
make life easy for people like that - you're supposedly a server admin,
that means you *have* to know how to use a grenade box. What, it's too
hard, the MCSE didn't prepare you?

Welcome to Real World, Bob the MCSE.

Basically, I'm less of a civic minded person than you :o)

-- 

Regards,
Phil

+------------------------------------------+
| Phil Mayers                              |
| Network & Infrastructure Group           |
| Information & Communication Technologies |
| Imperial College                         |
+------------------------------------------+



More information about the linux-elitists mailing list