Re: appropriate response for mail break-in

["Charles Swiger" <chuck () codefab com>]

"Bill Royds" <broyds () rogers com> wrote:
> On Sept. 25 and 26th a spammer forged my email address as from address for
> a "joejob" spam run. I have received over 8000 bounce messages since them
> (and I am still receiving them as of a minute ago).

Was the email sent to a specific list of domains or IP block, so you can
filter out the rejects?

> There is only one unforgeable thing in an email header, the immediate
preceding IP
> number that connected to your SMTP server to deliver the mail (the first
received
> line found in headers).

In terms of tracing the mail route, agreed.

Note that the envelope information in the "From" header (the one without the
colon, showing the argument to the SMTP "MAIL FROM:" command, not the
"From:" header in the message body) is also valid in the sense that it
unforgably reflects what your SMTP server was told.

> What a firewall can do is ensure that the SMTP connection is correct and
that
> the sender is on the outside of firewall and comes from the sending MTA
(sender
> domain has that MTA as MX or host is in same domain) and the receiver is
on the
> inside or vice versa. This is actually a stricter policy than most users
want,
> but it can cut down on spam and spoofing.

The majority of spam comes from IPs which don't reverse (that is, have PTR
records in the DNS, particularly around 210.0.0.0/7), or which reverse to
generic IPs within some dialup or broadband pool.

There is no correlation between the MX records for a domain and the mail
servers which might be responsible for handling mail sent from the users of
that domain.  Plenty of companies relay all of their mail via their ISP's
mail server, for example.  People also like to use mailing lists, such as
this one.  For that matter, a host performing SMTP need not have any DNS
records at all, if it's only sending outbound messages.

Let me put it another way: do you want your firewall to be proxying a
protocol as complicated as SMTP?  Do you want your firewall to be doing any
DNS lookups at all, much less making policy decisions based on DNS queries?

SMTP is much like HTTP; it's a very good protocol to proxy via a machine in
the DMZ of a screened subnet.  It's not something I'd want to run on a
firewall...again, do you want your security policy to depend on external
information in the DNS?  (Maybe one could build a virus scanner with
automated updates into one's firewall, too?  :-)

-Chuck

_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards