Hi Vernon, > > From: "Michael Mansour" > > > My setup involves two MX servers (call them mail2 and mail3) running > > sendmail, > > which: > > * handle all inbound mail for all domains > > * have dcc, virus scanning, SA, etc on them > > > > * once mail is scanned and found to be clean that email is passed to another > > server (call it main1) which holds the user mailboxes > > I trust that main1 does not do any spam or virus scanning, or if it > must, that it marks or discards hits instead of bouncing. Discarding
It currently does do virus and spam scanning (as it's used for smtp auth, pop, imap) so protects spam going out from such ppl. main1 is basically setup the same way as the MX servers although is not doing any MTA checks (greet_pause, throttling, etc). > is undesirable because it 'blackholes" false positives. Marking is not > good because mail that people must read is not really filtered. Bouncing > is worst, because so much mail has forged return addresses that bouncing > inevitably sends "backscatter" to innocent third parties and can get > your IP addresses blacklisted. Because it's only spam checking it's basically just upping the spam score a bit. I know it's not ideal at the moment, but one day I plan to spend time fixing it properly. > > I use dccm (for sendmail milter) and dccifd (for SA scoring). > > Why use both dccm and dccifd? That sounds likely to count mail recipeints > twice and so double the target counts and so probably push some mail > over your local threshold for bulk. > Why not instead just let SpamAssassin look for and parse the X-DCC > header added by dccm? Is what is already happening? I think > SpamAssassin skips talking to dccproc or dccifd when a mail message > already has an X-DCC header. Yes you're right, I only started using the dcc feature in sendmail a couple of days ago. I've now disabled dccifd and disabled the plugin in SA, added an SA rule to see the header and score it accordingly. Thanks for the tip on that one. > > I noticed that when the "temporary greylist embargoed" message would come up > > in the maillogs on say, mail2, sometimes the next connection for the same > > message would go to the alternate MX server, mail3. When messages were > > embargoed they literally were never released. > > There might be something else bad. Even if an SMTP client (mail > sender) alternates between mail2 and mail3 trying to send a mail > message, the third attempt after 10 minutes will hit an MX server > where the message has endured at least a 5 minute embago and so be passed. Test emails from hotmail seem to fail quickly (hotmail doesn't seem to wait the default 270s, multiple test emails sent from there fail regularly), while yahoo goes through most of the time. gmail takes a while and seems to not come through and not produce an error. Yahoo seems to produce the best error reports out of the three. During my tests today, I'd send an email from all three to: [EMAIL PROTECTED] and hotmail pops back with "undeliverable", yahoo with "User unknown" and gmail with "Recipient address rejected: User unknown in recipient maps table (in reply to RCPT TO command)" Looking at the yahoo error more closely, the test message I sent to: To: [EMAIL PROTECTED] was changed to: To: [EMAIL PROTECTED] which is why it bounced back with a "User unknown" and why gmail complained about the same thing. This is extremely strange. With dcc greylisting off, the MX servers work as expected by accepting the mail, doing the recipient checking with main1 via another sendmail milter, relaying the mail to main1 via mailertable entries. With dcc greylisting on, I get recipient map table failures and User unknowns. I control greylisting through the whitecommon file option: option greylist-off when I turn it off and: option greylist-on when I turn it on. What could possibly be wrong here? > > On each MX server I have a "localhost" greylist server running. I also > > > > After reading more dcc greylisting documentation, I realised that grey_flod > > should be used to share checksums with both MX servers, but looking at the > > grey_flod file for help in setting it up, well, I just don't know what to > > put > > in there. > > 1. Pick two distinct local DCC greylist server-IDs such as 32702 and > 37203 and add lines like these to /var/dcc/ids on mail2 and mail3 > > 32702 secret2 > 32703 secret3 > > where secret2 and secret3 are secret passwords. They can be the same. > > 2. set SRVR_ID=32702 on mail2 and 32703 on mail3 > > 3. restart `dccd -Gon` with > /var/dcc/libexec/rcDCC start > > 4. Add these to lines to /var/dcc/grey_flod on both systems > > mail2.example.com 32702 > mail3.example.com 32703 > > Because dccd ignores lines for its own server-ID, for simplicity > put both lines in both grey_flod files > > 5. watch /var/log/maillog or wherever system log messages from dccm > go for reports of typos. You should see both servers say they > are starting floods for the other. Thankyou for such precise instructions, I implemented this and flooding worked perfectly. > > Then after reading more documentation, I started to think whether both MX's > > need to run local greylist servers or do they need to be running from a > > central greylist server? > > Each instance of dccm or dccifd can use a remote greylist server by > deleting the reference to localhost in /var/dcc/maps and replacing it > with a reference to the server: > > cdcc "delete localhost Greylist" "add gserver.example.com 32769 secret" I did this by deleting localhost from both MX servers, and adding: mail2ip Greylist 32768 secret to mail2, and: mail3ip Greylist 32768 secret to mail3. > where secret is the password for client-ID 32769 in /var/dcc/ids on > gserver.example.com. > Traffic to and from UDP port 6276 on gserver.example.com must be allowed > by firewalls. They are part of the same subnet so that was ok. > It is nice to have 2 greylist servers for larger mail systems, so > that one is available when the other is down for maintenance or running > dbclean. The best way to do that is to > - define a new DNS name such as dccgrey.example.com with A RRs > for the IP addresses of the servers. Hmm... but wouldn't an RR request fail if the greylist server was down? > - ensure that client-ID 32769 has the same password in /var/dcc/ids > on all servers > - use `cdcc "delete..."` and `cdcc "add dccgrey.example.com 32769 secret"` > on all clients to tell them to use the servers named by > dccgrey.example.com As discussed above, I made both MX servers greylist servers, enabled flooding between them. I added both of them to each other using: mail2ip,- Greylist 32768 secret # *mail2ip,6276 ID 32702 # 100% of 1 requests ok 0.33 ms RTT 0 ms queue wait mail3ip,- Greylist 32768 secret # mail3ip,6276 ID 32703 # 100% of 1 requests ok 1.64 ms RTT 0 ms queue wait on one and: mail3ip,- Greylist 32768 secret # *mail3ip,6276 ID 32703 # 100% of 1 requests ok 0.35 ms RTT 0 ms queue wait mail2ip,- Greylist 32768 secret # mail2ip,6276 ID 32702 # 100% of 1 requests ok 1.72 ms RTT 0 ms queue wait and it seems to work. Michael. > Vernon Schryver [EMAIL PROTECTED] > _______________________________________________ > DCC mailing list [email protected] > http://www.rhyolite.com/mailman/listinfo/dcc ------- End of Original Message ------- _______________________________________________ DCC mailing list [email protected] http://www.rhyolite.com/mailman/listinfo/dcc
