Greylisting with multiple MX servers

Michael Mansour mic@npgx.com.au
Sat Apr 7 05:25:07 UTC 2007


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:

testuser@example.com

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: testuser@example.com

was changed to:

To: testuser@realmail3servername.realdomainname.com

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    vjs@rhyolite.com
> _______________________________________________
> DCC mailing list      DCC@rhyolite.com
> http://www.rhyolite.com/mailman/listinfo/dcc
------- End of Original Message -------




More information about the DCC mailing list

Contact vjs@rhyolite.com by mail or use the form.