Fwd: Re: [Mimedefang] Should I try to do MIMEDefang with Mailscanner forbackup MX

[alan premselaar]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Steve,

Steve Campbell wrote:
...snip...

>>
>>>> Why don't you just use sendmail to trow them away? As others already
>>>> pointed that out, you could provision your primary access database(s) to
>>>> the secondary (or make the secondary use the primary's access.db over a
>>>> TCP socket) and have sendmail do the rejecting without bothering
>> MIMEDefang.
> 
> I'm getting the feeling that I am not using sendmail properly with regards to
> mail accounts. Right now, whenever I need a new mail account, I just create a
> new user on the box. Imap and pop accounts are then available when needed. I
> dont add anything to the access files for users. For now, I just use the access
> files for spam, blocking IPs, and the like.

You're using sendmail properly.  My setup is nearly identical to yours
(only my primary MX is the primary MX for *ALL* my domains, and my
secondary MX is the secondary MX for *ALL* my domains, that's the only
difference)


> 
>> You could deliver the primary's access database to the secondary somehow 
>> (via scp/rsync, ftp, etc. like in every 5 minutes or so, or just when 
>> your primary access database gets updated, e.g. when you add a new 
>> mailbox) and merge both access files before building the access.db. Thus 
>> the secondary MX will always have all the information needed to reject 
>> mail coming to non-existing recipients for both of your domains.
> 
> My paragraph above sort of explains why this won't work, since my access file
> doesn't contain much. I'll look and see what it has, though, and maybe I can do
> something with it. 

Distributed access lists, while providing an independant means of
rejecting unknown users even if the primary MX is unavailable, is more
of an administrative burden.  Plus, if whatever system that provides the
list of valid users for you to distribute to your secondary MX is
unavailable, your access list will be out of sync and you could
potentially accept messages for no longer valid users and somewhere down
the road end up generating a DSN.

> 
>> If your backup MX is unable to reject unknown recipients when the 
>> primary is unreachable, it would need either to accept and queue 
>> everything and then relay that to the primary, or to tempfail 
>> everything. The first could result in a lot of junk and useless bounces 
>> clogging the queues, the second would be equivalent to not having a 
>> secondary at all.
> 
> Agreed, and the former is what it does at the present time.

if your MX servers are decent hardware, and regularly monitored /
maintained, your primary MX shouldn't be offline much (if at all) and
this shouldn't really be a big issue.

> 
> I kept wondering why everyone kept saying I didn't need MD, and now I see why.
> I'll have to rethink my entire access scheme. At the moment, all mailboxes for a
> domain are on the primary MX. If mail goes to the backup MX, it gets relayed,
> but only because I relay the entire domain to the where the mailboxes are (the
> primary MX for the domain).
> 
> It all used to be so simple.

It's still pretty simple.  The reason people are telling you you don't
need MD is because you apparently JUST want to reject unknown users on
your secondary MX.

of course, if you wanted to implement AV and SA scanning into your MD
filter, it makes sense to use it to do all of that, instead of using MD
to only check recipients against the primary MX and then using other
milters, etc to do the other functions.  especially since you can do so
much more with MD that could reduce (even more) the amount of mail
that's being processed by your AV scanner and SA (like bogus HELO
checks, greylisting, etc).

Also, since your primary MX is the secondary MX for *SOME* of your
domains, and your secondary MX is the primary MX for *SOME* of your
domains, you essentially make this process more difficult.  so you'd
either need to manage nearline access/virtual domain lists carefully
enough to know which is on which machine, or you'll need to write an MD
filter that'll check against the proper primary MX machine based on
which domain the mail is coming in for.

then you'll have to take into consideration "what happens if one mail
comes in for users in two overlapping domains?" (i.e. one domains's
primary MX is the other domain's secondary MX)

you could potentially use MD's stream_by_domain() functions, but then
that'll basically nullify your ability to 5xx reject mail and force you
to generate DSNs for even unknown users (which kind of defeats your
purpose and everyone elses' arguments about rejecting mail)


I would say that if you want to keep your (real) user accounts on two
separate servers for certain domains, then your ideal setup would be to
make each of those servers the primary MX for those domains respectively
and then install one or more additional servers as backup MX for all
domains.  since a backup MX isn't intended to be used for much traffic,
and only intended to queue mail if the primary MX is down, you should
have problem using an old (lower-spec) machine to do this.  I have my
backup MX machine running multiple other functions (such as backup DNS)
as well, since it basically just rejects mail on a regular basis since
my primary MX is *rarely* offline.

anyways, i hope this clears some things up and helps a bit.

Alan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEnLkeE2gsBSKjZHQRAtWjAKDZnwpL0hwldhRi45gjJOFi0AqENgCfcN/d
Z94R+ZIR2jrCTNKdMMgbB4I=
=yjF6
-----END PGP SIGNATURE-----