[Mimedefang] Should I try to do MIMEDefang with Mailscanner forbackup MX
mimedefang at asd.aplus.net
Sat Jun 24 06:10:10 EDT 2006
I don't mean to be offensive, but I think that some of your statements
are misleading and need additional clarification. Please see my replies
alan premselaar said the following on 6/23/2006 09:26 PM:
> Just to clarify, if the destination mailbox is local, then at least with
> sendmail an LDA (Local Delivery Agent) is required. I'm not familiar
> with other MTA software so I don't know if the LDA functionality is
> built-in to the MTA itself or not, but with sendmail a separate LDA is
> required. By default the LDA is procmail.
Procmail as LDA has not much in common with sendmail. Sendmail doesn't
get shipped with procmail nor procmail is part of the sendmail's default
delivery configuration. Procmail is an entirely separate package.
What sendmail comes with is called an _interface_ to "procmail", i.e. a
set of macros (hookups) like:
- FEATURE(local_procmail, ...)
- define(`PROCMAIL_*, ...`)
And here comes the confusing part (probably coming from 15 or so years
ago when there was just one LDA - procmail) - the above macro
declarations don't apply just for procmail, they are mandatory for _any_
LDA. For instance if you want to use maildrop, you still must declare it
with PROCMAIL_MAILER_PATH, FEATURE(local_procmail) and MAILER(procmail).
Perhaps that's why you thought it was bundled.
Sendmail also comes with a built-in local delivery capability defined
with "MAILER(local)" and capable of delivering to simple unix mailboxes
usually stored under /var/mail. Unlike real LDAs it's not even a
separate binary. Sendmail does the deliveries on its own and this is the
default delivery configuration.
>> 1. Sender <=> Primary MTA -> Mailbox
>> On your secondary MX however, the situation is quite similar to my
>> virtual domain setup. Here's what your delivery chain looks like:
>> 2. Sender <=> Secondary MTA <=> Primary MTA -> Mailbox
>> and here's mine:
>> 3. Sender <=> Primary MTA <=> LDA -> Mailbox
>> In both cases (#2 and #3) there's one middleman - your secondary MTA or
>> my primary MTA. I have also longer delivery chain with two middlemans in
>> case mail comes in through my secondary:
>> 4. Sender <=> Secondary MTA <=> Primary MTA <=> LDA -> Mailbox
>> In all of the above scenarios, leaving at least one middleman with no
>> clue about the destination end point what's valid and what not, creates
>> a gap which depending on the mail volume (or a dictionary attack for
>> instance) could quickly get filled with useless junk floating around.
> both sets of examples are identical, only in one set you've explicitly
> mentioned the LDA and in the first set the LDA is implied.
What matters here is whether the MTA really passes the delivery control
elsewhere or not. The "implied" LDA only exists theoretically and
behaves differently (actually it does not behave at all).
When sendmail delivers on its own (like the primary MTA does in case #1)
and the recipient is unknown, the message gets instantly _rejected_. It
doesn't get queued and there are no bounces to generate and deliver.
This is GOOD.
When sendmail relays (like the secondary MTA does in cases #2 and #4) or
passes the delivery control to a real LDA (like the primary MTA does in
cases #3 and #4), it has to _accept_ the message first (i.e, it enters
the queue), and then pass it forward (i.e. send it to the primary MX
over SMTP, or pipe it to an LDA). Then, if the final delivery fails,
there is a bounce message that would need to be generated, placed into
the queue and delivered back to the sender. This is BAD and need to be
We are talking about how to avoid or minimize these annoying bounce
backs. The idea it that the sooner you reject the undeliverable mails,
the smaller rainfall of bounce backs your servers would need to deal with.
So, back on the LDA subject, it does really matter what kind of LDA is
used (if any) and how the access controls are set up. You might like to
call the sendmail's built-in delivery-to-mailbox capability a full blown
LDA, but for my examples I find this rather confusing and prefer not to
> If your "middleman" is sendmail, then your explanation above is
Sometimes there are multiple middlemans and each of them could serve a
different purpose. In case #4 for instance there are two sendmail MTAs
in the middle - one secondary relay and one primary delivering to
virtual domains through LDA and there's nothing wrong with that.
Not equipping either one of the middlemans with the list of deliverable
local recipients (so they could be able to reject the undeliverable
emails) is just asking for trouble. I remember that before setting the
access controls on my servers some years ago (today it would be probably
much worse) I had queues constantly full with thousands of useless
bounces. Now these range up to a few hundred or so, primarily coming
from forwarders or going to inaccessible relays.
Having a secondary MX is still a good thing to have, though nowadays
it's somewhat harder to maintain. For example, recently I had one
primary MX (hosting some hundreds of virtual domains on a single IP
address) massively DDoS-ed for weeks with hundreds of bogus SMTP
requests blocking the legitimate incoming SMTP traffic. Having a well
working secondary allowed me to just firewall the junk and direct the
legitimate traffic through that secondary. Nobody noticed ;-)
What's important is to have all registered MX-es operate independently,
perform identical checks, reject as many undeliverable mails as they
could, and eventually reject more with MIMEDefang.
More information about the MIMEDefang