Goran,

Address validation is an absolute necessity unless you either want to spend extra money on multiple scanning boxes and/or suffer outages due to pure load.  As you add on more domains, the load from dictionary attacks on non-validated addresses will bury you.  If these bogus addresses make it through your spam blocking, they will then be bounced by your server when it tries to deliver them to their final destination creating an excessive amount of backscatter, and that is something that is intolerable IMO.

Sandy's ldap2aliases can be used for this, but IMO, it isn't something that I would use for multiple different Exchange servers as the configuration can be a bit much.  For one or two Exchange servers it would definitely be practicable.

The load from doing address validation on either ORF or within IMail is negligible.  The load from not validating addresses is enormous because of all of the extra volume.

Matt



Goran Jovanovic wrote:

Hi guys thanks for the info.

 

Another follow on question. In either the IMGate or ORF scenario can you only have an address list for some of the domains? So for some you would do the address validation and for others you would allow everything through?

 

I also assume that I could accomplish the same thing by using IMail aliases and using the ldap2alias tool that is floating around here? The problem as I understand with this solution is that the load is placed right on the IMail/Declude box and you don’t get any break for your poor overtaxed CPU. Correct?

 

 

     Goran Jovanovic

     The LAN Shoppe

 

 


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Nick Hayer
Sent: Thursday, August 04, 2005 6:10 PM
To: Declude.JunkMail@declude.com
Subject: Re: [Declude.JunkMail] Spam box

 

Hi Andrew -

Colbeck, Andrew wrote:

Also, I'd be a little skeptical that ORF would do the job for Goran, as he is basically an ISP for multiple organizations.

Common  :)   Don't be so negative..

He would need extracts from their GALs for each organization, or whatever the equivalent address list is for their internal mail.  I've no suggestion for that.

This is the long of it. The logistics of getting the extracts timely is the issue. He would have to figure that one out. There are some other quirks with ORF which I know you are aware but none the less it is a possible solution - depending on the circumstance. 

-Nick



 

Andrew 8)

 


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Bill Landry
Sent: Thursday, August 04, 2005 2:27 PM
To: Declude.JunkMail@declude.com
Subject: Re: [Declude.JunkMail] Spam box

----- Original Message -----

Sent: Thursday, August 04, 2005 2:10 PM

Subject: RE: [Declude.JunkMail] Spam box

 

I have a question about these boxes that go in front of Declude, be they IMGATE or ORF or whatever.

 

The way that I understand it from reading the threads here is that these front end boxes require the complete list of valid e-mail addresses for all domains that are being processed. Is that correct?

 

If that is correct, then perhaps someone who is gatewaying mail to clients could answer this. How do you get all the e-mail addresses on the front end box and how do you keep it updated?

 

I am doing gatewaying to various Exchange and other hosting providers and do not host any mail on my site. So am I correct in assuming that this solution will not work in my setup?

 

 

If you use a newer version of Postfix, you can use recipient address verification.  See http://www.postfix.org/ADDRESS_VERIFICATION_README.html#recipient for details.  However, the receiving mail server needs to respond properly.  If Exchange is set to blindly accept all forwarded mail and then bounce mail sent to invalid accounts, then it will always respond positively to verification queries, thus defeating the purpose of recipient address verification.

 

Bill


-- 
=====================================================
MailPure custom filters for Declude JunkMail Pro.
http://www.mailpure.com/software/
=====================================================


Reply via email to