Lets make one! Here are tid bit’s I have picked up over the past few weeks. Implementation Host MUST be on a NAT or outside address where it can see the real IP address of the last hop. Internet facing Reverse DNS on your hostname must work to prevet getting blocked by remote rDNS SPF rules. Default QmailToster will do minimal scanning. Spamdyke plus spamassasin should both be enabled for maximum protection. QmailToaster on CentOS 5 x_64 for a smooth install unless you like square pegs and round holes.
Configuration QMAILQUEUE will need to be reviewed for use case. QMAILQUEUE=""/var/qmail/bin/simscan” NOTE: you cannot have a trailing : on /var/qmail/control/simcontrol "attach=.exe:.pif:.src:" = All mail even NO attachments On Mar 12, 2014, at 9:32 AM, Jim Shupert <[email protected]> wrote: > > On 3/11/2014 3:09 PM, Eric Shubert wrote: >> On 03/11/2014 11:53 AM, Scot Needy wrote: >>> Yea, >>> >>> I guess that was my original question when I asked about NAT. >>> >>> Forgive me if I ask a dumb question but.. >>> >>> I thought that the source TCP address wasn’t an issue because much of the >>> spam prevention will look at mail headers not just the TCP source IP of the >>> last relay before mail got to qmail. >>> >> >> Depends on what you consider to be "much of the spam prevention". There's >> not really much in the headers that spamdyke or spamassassin relies on. >> Source IP address is probably the biggest single factor that spamdyke uses. >> >> You really need to get QMT on the perimeter (or behind a simple NAT) in >> order to have decent anti-spam effectiveness. >> > I do not wish to hiJack a thread ... but would like to say that a > comprehensive "best practice" suggestion list would be wonderful. > I am presently trying to 'knuckel down' on the spam problem. > > thanks > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected]
