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

alan premselaar alien at 12inch.com
Sat Jun 24 00:26:00 EDT 2006

Hash: SHA1

Atanas wrote:

> I primarily deal with non-standard sendmail setups hosting virtual
> domains (e.g. multiple mailboxes and multiple domains per single user)
> via local delivery agent (LDA) like procmail and maildrop, where
> sendmail acts as a middleman between the sender and the LDA.
> For your standard sendmail setup (i.e. one mailbox per user and no LDA)
> on your primary MX you don't really need that list in your access.db.
> Sendmail already knows how to deal with non-deliverable messages and
> effectively rejects them before entering the queue.

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.

>   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.

If your "middleman" is sendmail, then your explanation above is
incorrect.  sendmail needs to know the delivery path before it can
process the message for delivery. which means that sendmail knows if the
email address is valid or not.  if the email address is *NOT LOCAL*,
sendmail may not know the deliverability of the address, but it knows if
it's valid.

so, for instance, sendmail when receiving a message for user at domain.tld
first has to determine if it is to accept mail for domain.tld.  if it
doesn't accept mail for domain.tld, it has to determine which MX host
DOES accept mail for domain.tld and whether or not it is allowed to
relay the mail.

if sendmail *DOES* accept mail for domain.tld, then it checks to see if
user at domain.tld is local to this machine. if it is then it checks to see
if there are restrictions to sending to user at domain.tld (often with
access database or virtualuser database, etc) part of these checks are
to see if this user actually exists on this host.  this is part of
sendmails validation of deliverability.

once it is determined to be locally deliverable, the message is then
passed to the LDA for actual delivery.

I wanted to make these points clear because it seems that Steve may not
be fully knowledgable of the mail transport/delivery process and what
you've explained could potentially be *really confusing*.

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


More information about the MIMEDefang mailing list