"Catch 25"
- Date: Sat, 12 Sep 1998 16:53:13 +0200 (MET DST)
anti-spam@localhost, there has been some discussion on the RIPE
<anti-spam-wg> list and since I guess not everybody of you are on it,
I'm Cc:ing to get you involved.
I have a slightly different suggestion for the "Catch 25" problem,
i.e. where you force port 25 packets through some spezial device.
a) To date people have always suggested we put a sendmail/MTA in
place to take care of the SMTP connection we redirect (steal).
Please, do not do this!
- SMTP *is* end-to-end - please make it stay that way.
Don't tamper with Internet fundamentals!
- As man-in-the-middle you change *my* mail-routing, extremely
bad since that's really *my* business.
- I may use SMTP Auth, or some other, private, Auth which
depends on me speaking directly to my Home MTA (what I said
about IPsec in a previous mail was a no-brainer, sorry; but
this one is real).
- I may not trust your MTA to store any of my mail data; or
I may not trust your Postmaster to make sure it's delivered
(if you steal my SMTP connection, that's rather likely).
- I may be using a sendmail nullclient which depends heavily
on my Home MTA to clean up From: addresses etc. How my Home
MTA is configured to authorize relaying for me is beyond the
scope of this mail; SMTP Auth is one idea...
However.
b) Think of a (transparent, screening) firewall type device instead.
+ None of the "-" apply, since all you do is forward packets.
+ You can log all SMTP activity, connect/transfer/disconnect,
with hostnames, IP addresses and *accurate* time stamps.
+ You can scan and log the SMTP dialogue.
+ You can scan and log the RFC822 headers (DATA for SMTP, but
easily found).
+ You can scan and log (or classify) the mail text/content. If
the necessary anti-spam AI is developed, you can signal that
this particular SMTP carries spam. Wow :-).
+ If you have dialup AAA info you can even use that to apply
policy on a per-users basis. For leased line that's worse
but still not impossible to combine IP address & "MAIL From:"
in the strem you inspect.
- What you cannot easily do is force a disconnect. You can
throttle TCP by simply dropping some packets and you can
make the connection time out and close by dropping all of
them, but that's more indirectly, so to speak.
Now, there is quite some amount of work in both a) and b), work that
the ISP has to do. My guess is that it's very much the same for a)
and b), i.e. it makes little difference which one you use.
Gunnar Lindberg
