-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Atanas wrote: ...snip...
> > 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] is local to this machine. if it is then it checks to see if there are restrictions to sending to [EMAIL PROTECTED] (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*. Alan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEnL7YE2gsBSKjZHQRAnzZAJ9xYLy2efRKY3phTJV7l6G374FFAQCgrNjt FvjAW5htMKJEerVUVXBGYcY= =Fqyv -----END PGP SIGNATURE----- _______________________________________________ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list [email protected] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
