[H-GEN] Replacement?

[Tony Nugent]

[ Humbug *General* list - semi-serious discussions about Humbug and     ]
[ Unix-related topics. Posts from non-subscribed addresses will vanish. ]

On Tue Nov 05 2002 at 16:21, Sarah Walters wrote:

> Well, I've been thinking about the whole mail server issue (haven't really had
> time to look into my sendmail problem, hence no update) and I am thinking that
> sendmail might be more than I need anyway.

It depends...

> So I'm going to initiate a religious war by asking what MTAs people use
> and why? All responses welcome. I'm running FreeBSD 4.7 as a firewall, mail
> server, DNS (mostly internal at the moment, though accessible from outside)
> and of course ADSL gateway.

:)

> Minimum requirements:
> 
> Masquerade entire domain, including envelope. ALL mail going off that box
> or the workstations being the firewall should be masqueraded. Possible
> exception is the "From" field if it is set to an entirely different domain (in
> case I am subscribed to a mailing list on a different address) but I can live
> without that if necessary.

All that can be done.  (Using any MTA, not only sendmail).

But it will only work if all email is relayed through the mail
server on that box.  If you have any clients on a lan behind you,
then they will need to use it as the outgoing SMTP relay.

With sendmail, you'll need to build an .mc config file to include
all the appropriate masquerading directives and values, and perhaps
set it up to use a genericstable file too (to remap email addresses
on local outgoing email).

> Some form of spam filtering - currently configured to use RBL and bounce
> domains that can't resolve. I would also like to be able to bounce mail
> that is obviously spam.

Oh, hang on.

You were talking about outgoing email, now you are dealing with
incoming email.  There is a difference between what happens with
incoming and outgoing mail.

Outgoing email always involves smtp (as the target port on the
destination server).

Incoming email (if not an MX host) involves collecting email from
one or more remote mailbox accounts, using pop or imap (or their ssl
equivalents).

How are you wanting to achieve this?

Does an MX record in the DNS for your domain point to your public IP
address?  (no, it is on an adsl service).

So you are collecting your email from somewhere, I assume using a
pop client.  This doesn't (directly) involve sendmail at all.

If you use fetchmail, by default it will collect email from the
remote pop server and deliver it to sendmail (or directly to
procmail to bypass sendmail), which then passes it to procmail for
local delivery.  You can use fetchmail to collect email for
multi-drop mailboxes and all sorts of things.

Since procmail is involved, you can "plug in" spam and virus
scanning into the procmail delivery path, using either a global
/etc/procmailrc or a per-user ~/.procmailrc configuration.

Or you can go the full hog and plug in a milter program to run with
sendmail, for example mimedefang (www.roaringpenguin.com/mimedefang).
Which I suspect would be overkill for your situation.

> For example, our bigpond email address is forwarded to
> our home mail server.

Oh hang on (again).  Forwarded on?  I assume that it is forwarded on
to another email account and not directly (via smtp) to your home
mail server.

> Except for bills, most mail going to that address
> is spam. The envelope is addressed to our bigpond account, but the To field is
> a non-existant email address on our system. Whenever we see these we know they
> are spam. If there's any way to blackhole them that would be wonderful.

Be careful of actually bouncing spam, especially if you are doing it
via pop.  You should not do it at all unless you are a primary MX
host for a domain -- in the end it achieves little and will simply
cause you headaches in the long term with bounces to bounces and so
on.

Simply accept the spam (you have already - how else did you know it
was spam?), then either throw it into /dev/null or silently into
some spammer mailbox out of the way.  Besides, you don't want to
accidently throw away any non-spam with no way to retrieve it.  (But
I do bounce spam on an MX host with SA scores over 16 or so).

Same with viruses, they forge sender addresses so bouncing them just
doesn't work except to create noise, annoy and potentially infect
the innocent, and consume valuable bandwith.  Throw them into
/dev/null without reservation :-)

(There is a perl module called File::Scan that can be used to build
an effective perl-based virus scanner, and spamassassin/spamc can be
called directly from a procmail recipe).

If there is a way to close that spam-attracting email address, do
it :)

> Needs to handle aliases and be specified a few domains to relay (duh).

All smtp servers can do that :-)

But if you want to filter email that is being relayed *through* your
mail server (and not being delivered into local mailboxes), then you
will need to do filtering at the smtp level, using mimedefang or
some other sendmail milter (I'm not sure what other MTAs are capable
of).

> Don't give a damn about the mailbox format, as long as there is an IMAP server
> that can read it. Currently using imap-uw, but can survive if I have to
> switch.

Standard mailbox format would work well.  (wu-imap can also do mbx
format used by outrage excess, but you need to mess with a lot of
things to enable it, not recommended).

BTW, if you use imap then it is possible to use it to convert email
locked up in windows .pst files into standard mailbox format simply
by moving messages into IMAP mail folders.  Recommended.

> Security is a major issue. Setuid binaries - especially sitting on an
> open port ala older versions of sendmail - make me uncomfortable.

Security is an issue?  Then secure your name server so that it does
not answer queries to anyone not part of your local network :-)

Sendmail 8.12.x (don't use anything earlier than 8.12.5) has a new
security model, for example it no longer runs for local services as
suid root, but sgid root - a new smmsp user now exists to manage
locally generated emails.

> Thanks all.

There are lots of options to achieve what you want, just think of
how the mail flows around, and plug things in where appropriate.

> Mrs Sarah Walters

Cheers
Tony

--
* This is list (humbug) general handled by majordomo at lists.humbug.org.au .
* Postings to this list are only accepted from subscribed addresses of
* lists 'general' or 'general-post'.  See http://www.humbug.org.au/