On Tue, Nov 27, 2001 at 02:03:41PM -0500, Greg Ward wrote:
> On 26 November 2001, Malcolm Ferguson said:
> > I've tried to implement a system anti-spam filter. For example, I fail
> > messages with the header field X-YahooFilteredBulk. However, it seems
> > to me that this just moves my spam problem from my inbox to my message
> > queue (now I get lots of error messages frozen due to incorrect return
> > addresses). I could just silently dump the message, but I would prefer
> > to send some kind of failure feedback.
> Look at the sender_verify option to avoid those frozen bounces. That
> prevents messages with a fictitious sender domain from ever getting into
> your system. It doesn't keep out spammer999@???, but that's OK:
> your rejection message will be (in SMTP)
> mail from:<>
> rcpt to:<spammer999@???>
> so hotmail.com should just drop the rejection on the floor. You don't
> bounce bounces.
They'll do *WHAT*? No. I think you misunderstand a simple concept of
"reliable" mail delivery. Once your machine accepts the mail, as Malcolm
correctly mentions in his original post, it has a responsibility to try
and deliver it or bounce it. What will happen if it accepts a message from
an undeliverable address, which it then tries to bounce, is that when the
local exim tries to send the bounce, it gets refused, and exim can do
NOTHING, other than to freeze the message and attempt to draw the attention
of the postmaster.
If a human is involved, then it is basically reliable, because a human has
had to make the decision to drop it on the floor, and could try and warn
the relevant person that something bad has happened. However, under *no*
circumstances should hotmail, or any other mail server "just drop it on the
floor".
> > It seems to me that the system filter is applied after Exim has accepted
> > a message for delivery. This seems too late in the process - I don't
> > want to take responsibility for these messages. I would much rather
> > return 550 (or whatever the code is) to the client MTA instead of 220
> > and not accept the message at all, and make them deal with error. Is
> > there anyway of filtering at this earlier stage?
> Unfortunately, Exim 3 doesn't have this capability, so you can't filter
> based on headers or body content at SMTP-time. However, it's really
> easy to have a local sender address blacklist. Here's what I have in
> exim.conf:
I have a different system, that sits in front of my Exim, and calls back
to the MTA given by the from address to see if it will deliver a bounce.
Unfortunately, yahoo break this, because they only do verification after the
final '.'.
The system I use is called SAUCE:
http://www.chiark.greenend.org.uk/~ian/sauce/
> # Manual spam-blocking: any address matching a patten listed in
> # /etc/exim/spammers is blocked from sending mail to us.
> sender_reject = /etc/exim/spammers
This is a reasonable plan.
> /etc/exim/spammers is this:
[snap]
> Every time somebody pi**es me off, I put either their address or their
> whole domain in this blacklist. Works like a charm.
I on the other hand get to have a policy file that looks like:
* *@insideporn.net * 550 Spam return-path
*.monsterhut.com * * 550 Spam host
*.sfba.home.com * * 550 Dialup host - use your smarthost
Where I can customise the message they get back. The three fields are
sender-host, sender-from, recipient-to.
> For sender verification, I do this:
> # Reject mail with a bogus sender domain, but if the envelope sender
> # is bogus, look in the headers for a valid sender domain before rejecting.
> sender_verify
> sender_verify_fixup
> sender_verify_reject
I'm not convinced I like the idea of the middle one, but that comes down to
policy.
> Together, these two seem to keep the spam to a dull roar. They don't do
> anything for viral email though; if you're using just Exim, I think
Doing something with viral email during the response to the final '.' is
IMO, evil bad and wrong. You should try and keep the time to respond as
short as possible, and the sender-SMTP should try to wait for as long as
possible, as otherwise you end up with duplicated mail.
> you're stuck with accepting the message, scanning it, and rejecting it.
> sender_verify will keep you from getting lots of frozen undeliverable
> bounce messages, though.
I'm glad you now seem to understand the difference between freezing and
dropping on the floor.
MBM
--
Matthew Byng-Maddick <mbm@???> http://colondot.net/
