Title: Message
Matt:
 
>> gatewayed E-mail accounts.  Since IMail doesn't offer any way to validate gatewayed addresses or fending off dictionary attacks <<
 
With "gateway" you mean that you are hosting the "public" MX for them (primary and possibly backup MX), but you are NOT hosting their mailboxes on your own Imail machine?
 
Now I understand your application (I assume).  It means that ideally you'd want Imail to validate against an external user base - even if the mail domain itself is not hosted on Imail.  Yes - I do have the same need. 
 
It would be nice if Imail had a little "checkmark" in the mail domain configuration screen. If that checkmark for "remote domain" is set, then you could still choose an external "user database" and the SMTPD daemon would actually perform user validation. However, instead of doing an "LDELIVER" to a local mailbox, it would then perform an "RDELIVER" to the remote mailbox server.
 
In reality, all the pieces already exist in their code.  I think it's worthwhile to make THAT an enhancement request. It would further broaden the usability of Imail and reduce the need to look for alternative mail servers.
 
 
With a two scripts, you could probably already accomplish that:
 
a) on the client's remote mailbox server, export the user database for "domain.com" in intervals
b) on the clients' remote mailbox server, create an alias "incoming.domain.com".
c) on your Imail server, create a regular mail domain "domain.com".
d) run a script that reads the client's exported user database and creates an ALIAS in "domain.com" for every client USER, e.g. the user [EMAIL PROTECTED] becomes an ALIAS in your Imail configuration.  Point the alias to [EMAIL PROTECTED] and on your Imail server have a HOSTS entry for "incoming.domain.com" pointing to the client's remote server.
 
Now, when someone sends mail, it WILL be validated by the Imail server. If an alias does not exist, it can be rejected.  If it does exist, the mail will be processed by Declude and eventually it will be forwarded to the "incoming.domain.com".

Best Regards
Andy Schmidt

H&M Systems Software, Inc.
600 East Crescent Avenue, Suite 203
Upper Saddle River, NJ 07458-1846

Phone:  +1 201 934-3414 x20 (Business)
Fax:    +1 201 934-9206

http://www.HM-Software.com/

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt
Sent: Monday, February 09, 2004 04:42 PM
To: [EMAIL PROTECTED]
Subject: Re: [Declude.JunkMail] [Declude.Junkmail] MS SMTP LDAP Routing

Andy,

What's at issue here is expanding beyond just locally hosted E-mail accounts to gatewayed E-mail accounts.  Since IMail doesn't offer any way to validate gatewayed addresses or fending off dictionary attacks, it might well be wise to place MS SMTP before IMail on the same box, even if you only have locally hosted E-mail.  This obviously isn't an issue for the most part with backup MX's.

In relation to using IMail's LDAP, that might be too limiting and provide unnecessary overhead.  If you were to access the LDAP server on the same machine it wouldn't be that big of a deal, but in a fail-over situation where MX1 went down and MX2 is verifying off of the LDAP server on MX1, you would lose the verification capabilities.  The more eloquent solution that takes into account all of the various needs would be to dump an export into a text file and have the MS SMTP plug-in read it into memory.  You could then also allow those that want to do address verification for gatewayed E-mail to place a text file in a specific location and use that in addition to your IMail generated lists.

I think this would be more efficient than using LDAP, and it would allow for much greater flexibility.

Regarding dictionary attacks, router ACL's could certainly be used, however it might be much easier to get it all to work within the same application, i.e. MS SMTP.  You can reject at the HELO based on IP, and hardly any resources are used when that happens.  The hardest part will be defining what a dictionary attack is, for the same reason that SpamCop has lots of trouble with bulk mail.  It may be a better idea to just go with address validation which shouldn't be that much more data transmitted (rejected before the message is sent).  Dictionary attack detection is most helpful when the nobody alias is used.  It certainly seems that nobody aliases are a lost cause and maybe we should just forget that they exist :(

Matt

Reply via email to