Spam and mailing lists

[Ben Scott]

On 10/17/06, Jason Stephenson <jason at sigio.com> wrote:
> True. I will enumerate the reasons that I like Exim:
>
> 1. It is not Sendmail.

  Heh.  I'll admit to sympathizing to that one.  :)

  I'm no Sendmail expert, but from what I gather, Sendmail's original
major selling point was the ability to process all the different
protocols and message formats in use at the time.  Back before IP and
SMTP and RFC-822 took over the world, this was a big deal.  The
ability to write an entirely new protocol into the configuration file
was useful.

  These days, of course, anybody and everybody speaks SMTP.  Sendmail
has no problem with that, of course.  But it's still built around
those original design concepts, which makes things more difficult for
those who just want SMTP (i.e., just about everybody).

  Hence the popularity of qmail, Postfix, Exim, etc.

> 3. It is what I know.

  That counts for quite a lot.  Don't discount it.

> Again, it's probably not exactly the answer that Ben is looking for ...

  Actually, I think that's a very good answer, and I really appreciate
you taking the time to write that up.  While you of course could not
and did not attempt to significantly compare Exim to other MTAs, you
gave some reasons *why* you like Exim, and described a few of the
capabilities that you find useful.  You even put it in context of
spam-fighting.  So that's good stuff.  Thank you.

> Additionally, the above link points out something Ben may have
> overlooked in his original request. ...

  Indeed.  I was ass-uming that the mailer could just make its
decision based on the SMTP envelope; I wasn't thinking that people
might have the two differ on a mailing list like this one.  But that's
hardly an impossibility, so would need to be handled.

  Still, even if it has to accept an entire bogus message and *then*
reject it, that's still an improvement.  It would eliminate the hold
queue management problem while still giving diagnostics to most
mailers.  (I understand there are some mailers that ass-ume the SMTP
transaction cannot fail once DATA is issued, but I'm willing to call
that an "acceptable loss".)

> Ah, but the various bits of info used to authenticate a list member,
> whether you use the envelope sender or what's found in the From: or
> Reply-to:, are all supplied by the sender. All it takes for someone to
> spam or to send viruses to a subscriber-only list is for them to get the
> email address of a list member, or to become a list member. Since you
> cannot really trust what your MTA is told by the other end, I think it
> is better to have the AV and anti-spam than to not have it.

  Well, as far as AV goes, again, the plan is to employ attachment
stripping always, so there's no way for a virus to actually propagate
through the list.  Scanning what we're going to throw away is silly.
:)

  Now, as far as spam goes, I see two possible scenarios:

1. Spammer forges 'From' to match an existing subscriber, and sends to
the posting address.  List software allows the spam through, thinking
it's from a legit subscriber.

2. Spammer subscribes an address they control to the list, and posts from that.

  Now, I have been and continue to be subscribed to a great many
lists, and I've never actually seen a case of #1 happening.  Which is
not say it never has, or (more importantly) never will.  But for now,
I don't consider it a threat worth devoting resources to.  Maybe
someone the spammers will decide it's worth it.  (Rue that day.)

  #2 I've seen, but it's still pretty rare.  Same conclusion, with the
further factor that most spammers want everything to be strictly
one-way.  A valid return path makes tracing a lot easier.

  The recent "kidney" message that came across this list may have been
an case of #2.  It was apparently from an address that was subscribed
just before the message was sent.  I'm not sure what that was; it
didn't seem like traditional advertisement-type spam.  Not that the
reason for unwanted mail really matters *that* much, I suppose.

> However, Exim has a built-in ACL for every step of the SMTP transaction,
> and for every single SMTP command.

  That's pretty sweet.  I just may have to check out Exim after all.

> I already volunteered to help in setting up Exim for the list.

  You're hired!  ;-)

  Seriously, I may ask for your help doing just that.  First I'd like
to get a few kinks worked out of the existing system.  But don't be
surprised if I mail you in a month or three... :-)

  In the meantime, is http://www.exim.org/ the best place to go to
learn about Exim?

> You can also have an ACL that checks against a
> database during the connection and could possibly reject the connection
> based on the other end's IP address. (Yes, I know that IP blacklists are
> not popular here ...

  I know some people here do use them and like them.  It's really a
case of what one's needs are.  Some people are willing to accept more
false positives than others.

> ...  I maintain my own blacklist at work ...

  That's another difference.  If you're maintaining your own blacklist
(even if it's just a weighed amalgamation of third-party blacklists),
you have a lot more control over things.  Blacklist filtering tends to
go bad when someone uses a third-party blacklist with an aggressive
listing policy as the sole criteria to reject.

> Well, I've been hammering at this for over an hour, and I should have
> gone to bed a while ago.

  Me too.  ;-)

> I hope the above information is helpful to
> someone/anyone who is thinking about choosing a MTA. ;)

  Indeed, it was, and thanks again for sending it.

-- Ben