I am mulling over the thought of replacing my current solution, it works very well except for the following two issues:
1. LDAP recip verification for only one server, this gateway services multiple domains who's directories are independent. I need to be able to verify the various domains off of independent servers.
2. I use backup mx's, my current solution probably could work in this scenario but the support mechanism behind it is *very* weak and I can't get a perfect setup working. Spam hits the primary for a domain, gets blocked and then tries my secondary which sometimes accepts it, after which the primary always accepts from the secondary.
What are some setups that use Postfix which you guys are having very good success with that isn't a burden to administer. The last thing I want to do is replace my one single app with many:)
Thanks for any ideas! jlc
Joseph L. Casale wrote:
I am mulling over the thought of replacing my current solution, it works very well except for the following two issues:
- LDAP recip verification for only one server, this gateway services multiple
domains who's directories are independent. I need to be able to verify the various domains off of independent servers.
- I use backup mx's, my current solution probably could work in this scenario but
the support mechanism behind it is *very* weak and I can't get a perfect setup working. Spam hits the primary for a domain, gets blocked and then tries my secondary which sometimes accepts it, after which the primary always accepts from the secondary.
If you have a secondary mx, it MUST have the same (if not more aggressive) spam prevention as your primary for this exact reason. You also need to make sure that the secondary can reject mail for non-existent users so you don't send backscatter when the primary rejects the mail.
What are some setups that use Postfix which you guys are having very good success with that isn't a burden to administer. The last thing I want to do is replace my one single app with many:)
Can't help you there. I don't use Postfix.
Here is my problem
[root@shannon CGPMcAfee]# ./updateDatFiles CGPMcAfee DAT files update program version 2.2 Local avvDAT version is 5726 Connecting to 'update.nai.com' [72.247.238.178:80] via HTTP protocol... *** failed to connect: socket error
The problem is that I can't change the script and I'm under a proxy server, but the updater ignore it. Same happen with others updaters
WHAT CAN I DO?
Best Regards
Saludos Fraternales _____________________________ Atte. Alberto García Gómez M:.M:. Administrador de Redes/Webmaster IPI "Carlos Marx", Matanzas. Cuba.
On Mon, 2009-09-28 at 17:49 -0400, Alberto García Gómez wrote:
Here is my problem
[root@shannon CGPMcAfee]# ./updateDatFiles CGPMcAfee DAT files update program version 2.2 Local avvDAT version is 5726 Connecting to 'update.nai.com' [72.247.238.178:80] via HTTP protocol... *** failed to connect: socket error
The problem is that I can't change the script and I'm under a proxy server, but the updater ignore it. Same happen with others updaters
WHAT CAN I DO?
I'm not sure if it'll work with that specific updater, but maybe try:
export http_proxy="http://$USERNAME:$PASSWORD@$PROXY_ADDRESS:$PORT"
Regards
Hamzah
Alberto, please don't reply to a previous email and change the subject line. Click on New Message when starting a new topic.
You screw up the threading, and is considered thread hijacking.
Hi,
2009/9/28 Alberto García Gómez alberto@ipimtzcm.rimed.cu:
Here is my problem
[root@shannon CGPMcAfee]# ./updateDatFiles CGPMcAfee DAT files update program version 2.2 Local avvDAT version is 5726 Connecting to 'update.nai.com' [72.247.238.178:80] via HTTP protocol... *** failed to connect: socket error
The problem is that I can't change the script and I'm under a proxy server, but the updater ignore it. Same happen with others updaters
WHAT CAN I DO?
Ask McAfee/NAI, since they are the providers of that script. I doubt it that you are their only customer who needs to update behind a proxy/firewall and it's probable that they have a way to use a proxy in the request.
Other than that, if you have access to the proxy server you might be able to set up a transparent proxy, but that is a complex setup that requires you to really understand your network topology... Or, if that is possible for you (e.g., you already have NAT setup) you could choose to open your firewall to allow that one access from that server to the NAI website only without going through the proxy.
HTH, Filipe
Am 28.09.09 23:49, schrieb Alberto García Gómez:
Here is my problem
[root@shannon CGPMcAfee]# ./updateDatFiles CGPMcAfee DAT files update program version 2.2 Local avvDAT version is 5726 Connecting to 'update.nai.com' [72.247.238.178:80] via HTTP protocol... *** failed to connect: socket error
WHAT CAN I DO?
a) do not make threads of others your own. b) Ask McAfee? You bought their application, they should give you support.
Ralph
Bowie Bailey wrote:
Joseph L. Casale wrote:
- I use backup mx's, my current solution probably could work in this scenario but
the support mechanism behind it is *very* weak and I can't get a perfect setup working. Spam hits the primary for a domain, gets blocked and then tries my secondary which sometimes accepts it, after which the primary always accepts from the secondary.
If you have a secondary mx, it MUST have the same (if not more aggressive) spam prevention as your primary for this exact reason. You also need to make sure that the secondary can reject mail for non-existent users so you don't send backscatter when the primary rejects the mail.
Personally I'd just drop the secondary mx completely and let the sending smtp server queue the mail whenever you're offline. Makes life a lot simpler.
Ned Slider wrote:
Bowie Bailey wrote:
Joseph L. Casale wrote:
- I use backup mx's, my current solution probably could work in this scenario but
the support mechanism behind it is *very* weak and I can't get a perfect setup working. Spam hits the primary for a domain, gets blocked and then tries my secondary which sometimes accepts it, after which the primary always accepts from the secondary.
If you have a secondary mx, it MUST have the same (if not more aggressive) spam prevention as your primary for this exact reason. You also need to make sure that the secondary can reject mail for non-existent users so you don't send backscatter when the primary rejects the mail.
Personally I'd just drop the secondary mx completely and let the sending smtp server queue the mail whenever you're offline. Makes life a lot simpler.
I agree. That's why I started with "IF you have a secondary..." :)
Personally I'd just drop the secondary mx completely and let the sending smtp server queue the mail whenever you're offline. Makes life a lot simpler.
I agree. That's why I started with "IF you have a secondary..." :)
trust me, I also agree 100%, but users on sourceforge and other mailing lists suffer if a mx is down for maintenance. If several messages are being delivered as in the case of busy lists like Fedora/asterisk/freeswitch, the bounce level goes through the roof too quickly. In *all* other cases, the RFC correct functioning servers don't even hiccup.
How do I keep users on sf lists from getting put on hold?
Thanks! jlc
Joseph L. Casale wrote:
I am mulling over the thought of replacing my current solution, it works very well except for the following two issues:
- LDAP recip verification for only one server, this gateway services multiple
domains who's directories are independent. I need to be able to verify the various domains off of independent servers.
Postfix can handle that. You can have multiple lookup tables/maps. They do not even have to be the same type of database.
- I use backup mx's, my current solution probably could work in this scenario but
the support mechanism behind it is *very* weak and I can't get a perfect setup working. Spam hits the primary for a domain, gets blocked and then tries my secondary which sometimes accepts it, after which the primary always accepts from the secondary.
Like others have already said, lose it or fix it.
What are some setups that use Postfix which you guys are having very good success with that isn't a burden to administer. The last thing I want to do is replace my one single app with many:)
postfix + spamass-milter will do it.
Postfix can handle that. You can have multiple lookup tables/maps. They do not even have to be the same type of database.
I guess I can leave that part upto Postfix, but I still need a antispam addin...
I asked on the Postfix list a while ago whether multiple LDAP server lookups could be configured and received no response. I assumed no one had done it. I'll just have to reserve some time to actually try it!
Like others have already said, lose it or fix it.
Well, therein lies my trouble. With the poor support around my current product I can't fix it (Don't know how). I had to loosen up the primary so it would stop rejecting good mail from the secondary, it's nothing short of a proper mess, I know. Hence the look for alternatives....
postfix + spamass-milter will do it.
I'll give a second look at sa, I haven't looked at it in a while (years) but remember it being rather indepth.
Thanks!
Joseph L. Casale wrote:
Postfix can handle that. You can have multiple lookup tables/maps. They do not even have to be the same type of database.
I guess I can leave that part upto Postfix, but I still need a antispam addin...
spamassassin via spamass-milter. Fast, no complicated smtp proxy/multiple queue setup needed and not as resource intensive as some other solutions.
I asked on the Postfix list a while ago whether multiple LDAP server lookups could be configured and received no response. I assumed no one had done it. I'll just have to reserve some time to actually try it!
:-D
I have not bothered with that list in ages. You can put multiple ldap table lookups directives in main.cf. Each directive has its own configuration. If you are not going to rewrite the recipient address, put the domains in the 'relay_domains' list (you can put a filename here and put the domains in that file) and then feed the list of ldap lookups to 'relay_recipient_maps'.
Eg:
relay_recipient_maps = ldap:/etc/postfix/domain1.cf, ldap:/etc/postfix/domain2.cf ldap:/etc/postfix/domain3.cf (they do not need to be on one line but the continuation must be indented)
Each domainX.cf should have a 'domain' parameter to prevent unnecessary queries. Eg: domain1.cf should have a domain = domain1 entry. Ldap configuration file information: http://www.postfix.org/ldap_table.5.html
Like others have already said, lose it or fix it.
Well, therein lies my trouble. With the poor support around my current product I can't fix it (Don't know how). I had to loosen up the primary so it would stop rejecting good mail from the secondary, it's nothing short of a proper mess, I know. Hence the look for alternatives....
Your secondary should have the same filtering setup. Also, a queueing secondary is absolutely useless. Just let the mails queue at their original servers. If they bounce due to stringent rules (one hour delay and boom! that's it) then let them. Better that they know the mail has not gone through than to think it has and wonder why there has been no reply for the next two/three days. People have this 'instant' concept about email. I would not bother with a 'secondary' anymore.
postfix + spamass-milter will do it.
I'll give a second look at sa, I haven't looked at it in a while (years) but remember it being rather indepth.
Yeah, if you need to some tweaking of rules.
-
Alberto García Gómez -
Bowie Bailey -
Christopher Chan -
Filipe Brandenburger -
Joseph L. Casale -
M. Hamzah Khan -
Ned Slider -
Ralph Angenendt -
Spiro Harvey