Re: [Declude.JunkMail] Using Imail/Declude as Public Gateway

[Matt]

Andy, You do understand, however you are also leaving off a piece of the utility.  If you are running a gateway service, it might be nice to force your customers to subscribe their addresses.  Postini does this for instance and for good cause...it prevents them from needing to accept every E-mail, and it also leaves an auditing trail for charging the customer.  There is a question though as to requiring your customers to subscribe each address being overly burdensome.  I would probably approach it as a cheaper service since otherwise I would be processing more E-mail, so if they want no administration, they pay more and deal with the consequences of bouncing E-mail to bogus addresses (if it gets through Declude). Regarding your work around, it definitely looks like it would work.  I am however apprehensive to ask that a client do more than the DNS change that is required, and in some cases this isn't possible if their E-mail is provided by yet another party who doesn't care to work with your solution because they are reselling something like Brightmail (I have one such customer currently).  Besides, it seems like a bit of overkill. If you are running a secondary MX off of MS SMTP instead of buying IMail, then it makes sense to have this all inside of that one application.  It does produce overhead though when paired with IMail on the same box, so it would probably be best to add functionality to filter out obvious spam with additional tests.  To start though, I think this first step will be easy to do. Matt Andy Schmidt wrote: 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 -- ===================================================== MailPure custom filters for Declude JunkMail Pro. http://www.mailpure.com/software/ =====================================================