Greylisting with multiple MX servers

Vernon Schryver vjs@calcite.rhyolite.com
Sat Apr 7 15:22:31 UTC 2007


> From: "Michael Mansour" 

> Because it's only spam checking it's basically just upping the spam score a
> bit.

The correct, although less popular way to use the DCC is with local
thresholds defining "bulk."  If a mail message must be checked more than
once for DCC target counts, the second and subsequent checks should
be done with -Q so that a message that is not bulk does not become bulk
and so get branded as unsolicited bulk email or spam. 

Instead of running with -Q, you could whitelist your exterior MX servers
by with mxdcc lines in whiteclnt files, provided you are using the
current version of the DCC source instead somethink like the more than
2 year old version that Debian is still pushing.

Local systems running browsers as MUAs that cannot be trusted to not
become infected with a trojan proxy and that cannot tolerate 4yz
rejections of greylisting should be whitelisted with "submit" lines,
but that's an unrelated story.


> I've now disabled dccifd and disabled the plugin in SA, added an SA rule to
> see the header and score it accordingly.

Again, I thought the SpamAssassin plug-in already includes a regular
expression that detects X-DCC headers.


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

I hope you mean "least bad error reports," because none of the three
you report are useful.  You need an honest copy of the SMTP response
from your SMTP servers, not a supposed distillation.

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

None of those messages are really useful.  You need a copy of SMTP response
string that your sendmail processes are sending.

Many years ago Hotmail refused to pass the SMTP responses to users, but
then they mostly fixed that.



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

Are you using greylisting on your interior SMTP server?  Have you checked
the Received headers to ensure that what you are seeing is not a bounce
from your mail2 or mail3 reporting that your mail1 did not like the address?

I think you said you are using dccifd on your interior mail1.
Have you whitelisted your mail2 and mail3 systems for mail1 with lines like
these in whiteclnt on mail1?  
mxdcc  ip mail2
mxdcc  ip mail3

As the `man dcc` man page tries to say, "mxdcc" whitelisting should
be used to tell your interior SMTP servers about mail that has already
been DCC checked.


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

Today, it is generally a bad idea to have SMTP MX secondaries as
backups.  Multiple SMTP servers are necessary if one can't handle all
of the mail you receive, but old fashioned MX secondaries cause a lot
more trouble today than they prevent.  15 or 20 years ago you needed
MX secondaries to receive and queue mail when your primary was down,
because you could not rely on distant SMTP clients to do their own
queuing and retrying.  Today all mail sendesr except many spammers do
good jobs of retrying--sometimes too good as with common configurations
of sendmail that retry once every 1 or 2 seconds.  Even some spammers
retry reliably.

DNS differs from SMTP.  You must have DNS secondaries and they must
be dispersed both geographically and topologically.  If not, you will
lose mail as well as HTTP hits and other things that often to translate
to money.

So to answer the question, a DNS RR request must never fail and not
merely for the DCC clients.  (Never mind that the DCC clients only
re-check the DNS resolutions of DCC servers every couple of hours and
I think they do the right thing if DNS does fail.)

 ...........


] From: "Michael Mansour" 

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

I cannot see how turning on DCC greylisting could cause that.

Please try using "mxdcc" lines in your whiteclnt files.


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

I do not see how that is relevant.  It seems to me to be saying what
I said before.  If you do not synchronize the greylisting databases
of your MX servers (as most greylisting implementations do not), then
greylisting embargos can be inflated N times, where N is the total
number of MX servers.


Vernon Schryver    vjs@rhyolite.com



More information about the DCC mailing list

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