server-based spam solution

"Tzadik Vanderhoof" <Tzadik.Vanderhoofcavtel.net> writes:

> If I'm willing to learn are you willing to
> help me out (answer questions, etc.)?

Absolutely. That's key to being part of a community, it
being willing
to help others learn.

To give you an example of this at its extreme, a bank I use
was
sending mail wrongly to me, it bounced off my server, and I
spent a
half-day with them on the phone until I talked to the right
person
who, I think, sort of understood the issue and agreed that,
at the
very least, I wasn't asking for anything outside the RFCs.

I think the best thing to do to learn about mail is to get a
book on
it. Assuming you already know the simple stuff, like that
there is a
protocol called SMTP (don't laugh, I know of mail admins
who don't
know what that is), then let me suggest the Sams book on
Python. It's
not up to date. Many of the configurations in the book
don't work, but
the basic concepts are clearly laid out.

There may be other books. I don't know them.

> I think the first step would be to switch from sendmail
to
> postfix.

As the risk of pissing the one or two Sendmail employees on
the list off, yes.

Postfix is simple, scalable and easy to work with. It's a
pleasure.

> I actually have 2 web servers, 1 which is older
> has sendmail and a "newer" one with
postfix.  But I tend to
> be on the "conservative" side... I don't
like to do anything
> that could get my machine into a broken state that I
may not
> be able to quickly fix, and switching from sendmail to
> postfix strikes me as one of those situations.  The
> situation is a bit more complicated, because I also
have
> majordomo running.  Do you have any experience doing
that
> switch, and keeping majordomo?

I've never set of majordomo so honestly I don't know.

I see that the Postfix FAQ mentions some Majordomo issues.
Those are
things you may want to be aware of.

> I don't know right now how to do all those things. 
From
> what I can tell, you're not recommending installing
any
> product... everything involves just configuration,
right? 
> In any event, can you point me in the right direction
to
> learn how to do it (other than "google
it"

The problem with these programs SA, etc. is two fold.

The first is they are soft of black boxes. People who don't
know much
about mail install them, and they just say "I use
SpamAssassin." but
they don't really know what it does. Of course there are
folks who do,
but I think SA in particular aims for the crowd that
doesn't.

And that's okay, except for the fact that these are the
same sorts of
folks I have to deal with when thier mail doesn't deliver
and they
can't follow the conversation.

The second problem is that, as your mail infrastrcture is
concerned,
it shift the problem to a place that's "too
late" IMHO. In the case of
SA and others, you accept the mail for delivery, then you do
stuff to
it, tag it or throw it away.

IMHO that's too late. You want to be able to say right up
front "Don't
come to me with your junk", and save your cycles, disk
and network for
real mail.

Now SA advocates would say "Yes, but we can't know
what's good and
what's not." and that's true. What we can say is
"Do you meet certain
criteria for getting in the door?" and those criteria
are things like,
"Do you meet certain standards set by the IETF for
mail servers?" "Are
you on a blacklist?" "Are you a mail server
authorized by this domain
to be sending mail on thier behalf?" and "If you
want to send mail to
me, can I send mail back to you?"

And litterally, those are the questions that my mail server
asks,
thorough configuration.

If you pass those qualifications (which IMHO are pretty low)
then you
get delivered[1]. If not, then I can reject the mail right
on the
spot. I don't perform any tricks. I don't look for too
many
capitalized letters (like SA does) or do any cheksums of the
mails.

I find this method amazingly fair too, because I can point
to the
problem and say "The reason you saw a bounce was
XYZ."- and it does
happen. I've had problems with broken mail servers that
required
legroom. On the other hand, in the end, I've usually been
thanked, or
at the very least, the mail administrator acknowledged that
the
problem was on thier end.

And in the grand scheme, if you're willing to go down that
road with
me, if a majority of mail administrators took these
positions, then
the problem would correct itself. Badly configured mail
servers would
get corrected, and spammers would have less and less
channels by which
to get in, forcing them to go through the front door, and be
identified and locked out faster.

Over the last five years, I've seen spam levels decrease
for just this reason.

Now, back to the matter at hand... If you *do* do
post-processing of
mail, through SA, for example, since you just forward mail
(rather
than deliver through IMAP) you'll have only two choices: to
tag it or
to throw it away. Tagging sounds good, but that means that
you haven't
solved the problem, you've pushed it back to the client
again!

Throwing it away sounds good, but that's even more
dangerous, since
you now have a black hole for mail! Someone sends a mail,
they don't
get a bounce, and the recipient doesn't get it. Icky.

The RFC says *never* black hole mail. I agree, with one
exception for
virus mail, which I think can be safely put away in a
quarantine and
examined by a human (sometimes if you configure ClamAV or
amavisd
wrong, you can get "false positives" like all
.zip files being
quarantined).

Anyway that's my little rant explaining why I take the
position I do
about mail. I don't want to hurt anyone's feelings, I just
want to try
to increase awareness of the issue.

If you have any questions on implementation, this list seems
as good a
place as any.

- Serge

[1] Or at least then go through the door for processing.
_______________________________________________
dclug mailing list
dclugtux.org
http://www.
tux.org/mailman/listinfo/dclug

server-based spam solution

Thread: server-based spam solution