Thanks to John for stepping in! Everything he said is on-point.
I am, stupidly, still up. This will be my last post for tonight,
though.
1) I have a mix of gatewayed domains and locally hosted domains. It
seems that this script is really built for locally hosted domains
and would need to be extended to say take in addresses stored in a
flat file or database. Is that correct?
The script doesn't discriminate between mailbox servers located
"behind" your MX on an internal subnet and mailbox servers located on
another site entirely. It uses LDAP/TCP for all transport and has no
difficulty traversing a WAN (in fact, it is especially useful in such
scenarios).
However, it _does_ discriminate based on the MTA vendor and LDAP
flavor in use on the mailbox server. It has been written specifically
for IMail 8.12 with its built-in OpenLDAP. Can be tweaked for any LDAP
server, particularly AD (in fact, exchange2aliases is a close
approximation of such an AD tweak of ldap2aliases). I had no intention
of supporting IMail's LDAP prior to the OpenLDAP introduction, since
it was totally buggy. Using the standard OpenLDAP platform has made
these scripts possible, a good call by Ipwitch.
2) I'm unfamiliar with IMail's ability to do envelope rejection
based on LDAP data. Could you explain how this works, or possibly
point me to a relevant article from Ipswitch on how this works?
IMail will be doing envelope rejection not based on LDAP interaction
during the envelope, but on its traditional alias check. Every user on
the mailbox server has an alias on the MX. SMTPD isn't speaking LDAP.
(I really shouldn't mention this now, but we do have a tool that does
allow IMail's SMTPD to query LDAP in real-time...since you guessed
that way. But that's not at all what's happening with this solution.
Pay no attention.)
I'm also curious as to how Declude would see these addresses, i.e.
is everything set up as an alias on the scanning server where say
[EMAIL PROTECTED] would be aliased to
[EMAIL PROTECTED]?
There's a virtual host, storeforward.mailpure.com, on the MX. This
host has a host alias for mailpure.com. There's a standard alias,
forums, under storeforward.mailpure.com. Its target is, for example,
[EMAIL PROTECTED]. The IP of mail1.mailpure.com, the mailbox
server, is entered in the HOSTS file on the MX or listed in DNS with a
traditional MX record.
Depending on the SWITCHRECIP setting, I believe Declude sees these
users as being under storeforward.mailpure.com or mail1.mailpure.com.
Whichever it is allows for all of the usual user.junkmail files.
3) Some domains of course use nobody aliases, and some gatewayed
domains don't have complete lists of users available. I'm wondering
if and how this is handled on the gateway server?
Well, you just wouldn't run the sync script for domains for which you
_need_ to accept all mail--it's that simple. They'd remain standard
HOSTS-routed remote domains.
4) I'm wondering about how the lookups happen. Is the information
pulled completely to the MX server when the script is run, or is it
queried off of the mail server every time a message comes in?
Whenever you run the script, the alias info is pulled from the mailbox
server. If the script fails to run because the mailbox server can't be
reached, the last retrieved aliases just stay in place, a failsafe.
HTH.
--Sandy
------------------------------------
Sanford Whiteman, Chief Technologist
Broadleaf Systems, a division of
Cypress Integrated Systems, Inc.
e-mail: [EMAIL PROTECTED]
SpamAssassin plugs into Declude!
http://www.mailmage.com/products/software/freeutils/SPAMC32/download/release/
Defuse Dictionary Attacks: Turn Exchange or IMail mailboxes into IMail Aliases!
http://www.mailmage.com/products/software/freeutils/exchange2aliases/download/release/
http://www.mailmage.com/products/software/freeutils/ldap2aliases/download/release/
---
[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]
---
This E-mail came from the Declude.JunkMail mailing list. To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail". The archives can be found
at http://www.mail-archive.com.
