Greylisting with multiple MX servers

Michael Mansour mic@npgx.com.au
Sat Apr 7 11:51:49 UTC 2007


Hi Vernon,

> > 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
> 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.
> 
> > 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.
> 
> > 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.

As a follow-up to my previous email, I think I'm starting to understand why
messages were never released, it's because they were rejected.

I tell the MX servers, via the sendmail relay-domains and the mailertable
file, to use the main1 smtp server to relay any mail they receive. I can't see
any other reason why hotmail, yahoo, gmail would all have a bounce back of
"recipient address rejected: user unknown in recipient map table" if the
sendmail delivery rules were being followed. 

It seems what is happening is that the message is embargoed, then let's say it
passes, the greylist doesn't attempt to follow the sendmail rules at
delivering the message to "main1" but instead tries to find the recipient on
the MX server it's run on. This is why the message gets bounced with a
recipient map problem.

Is there something I need to configure in dcc files to "fix" this behaviour?
or things I have to check for?

In each whiteclnt file I have the MX server ip's with the "mxdcc" value.

I also run the:

/usr/libexec/dcc/hackmc -T /usr/share/sendmail-cf/m4/cf.m4 sendmail.mc >
sendmail.cf

on my sendmail.cf after I build the from the mc.

In regards to the other issue I had with smtp clients talking to multiple
MX's, I've done some research and here:

http://hcpnet.free.fr/milter-greylist/

you can see this bit:

***
Multi-MX sync

When using multiple MX, the sequence of delivery attempts can become
complicated, and if the sending MTA does not try all the MX servers, the
delivery can be much longer. milter-greylist has a multi-MX sync feature, that
enable the database to be shared by all the MX servers.
***

where the developer seems to have dealt with this problem effectively.

Thanks.

Michael.

> > 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.
> 
> > 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"
> 
> 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.
> 
> 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.
>   - 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
> 
> 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.