BAD_RCPT_THROTTLE and greylisting

[Aristidis Fesarlis]

I was wondering if the above cannot coexist. It seems that sendmail
treats the temporary failures produced by greylisting (smf-grey in my
case) as bad recipients, enabling throttling. This results in mail from
specific senders who send a lot of mail to us never to be delivered.

Does that sound reasonable to someone? If this happens indeed, I would
appreciate some guidance.

At the moment my BAD_RCPT_THROTTLE is set to 3.

[Aristidis Fesarlis]

anyone?

[Bruce Esquibel]

Aristidis Fesarlis <fesa...@gmail.com> wrote:

Well, just the obvious...

If the problem is "specific senders who send a lot of mail to us", why not
just whitelist them to skip over the checks.

Honestly, I gave that whole smf group (grey/sav/spf/zombie) a good run a few
years ago, but eventually gave up. If memory serves, the grey one was the
first to go. I don't remember any problems with it and sendmail, but dealing
with all the broken mailers out there just created a lot of work and didn't
really help in the long run.

Even if it worked as it should, too many people bitching about delays in the
receiving of the mail, work related mostly.

I mean it depends on the clients and what kind of mail you are processing
but these days with more people on smartphone type devices, they expect
their message to be delivered a few seconds after the send button is hit.

My opinion, keep the BAD_RCPT_THROTTLE and dump the greylisting, besides for
a few machine-gun spam sources which are easier to block via the access
table or firewall, the greylisting doesn't seem to help with spam and causes
too many problems with legit mail deliveries.

Or just start whitelisting the legit servers. I think the control file by
default was in /etc/mail/smfs/smf-grey.conf.

-bruce
b...@ripco.com

[Aristidis Fesarlis]

> Well, just the obvious...
>
> If the problem is "specific senders who send a lot of mail to us", why not
> just whitelist them to skip over the checks.
>
> Honestly, I gave that whole smf group (grey/sav/spf/zombie) a good run a few
> years ago, but eventually gave up. If memory serves, the grey one was the
> first to go. I don't remember any problems with it and sendmail, but dealing
> with all the broken mailers out there just created a lot of work and didn't
> really help in the long run.
>
> Even if it worked as it should, too many people bitching about delays in the
> receiving of the mail, work related mostly.
>
> I mean it depends on the clients and what kind of mail you are processing
> but these days with more people on smartphone type devices, they expect
> their message to be delivered a few seconds after the send button is hit.
>
> My opinion, keep the BAD_RCPT_THROTTLE and dump the greylisting, besides for
> a few machine-gun spam sources which are easier to block via the access
> table or firewall, the greylisting doesn't seem to help with spam and causes
> too many problems with legit mail deliveries.
>
> Or just start whitelisting the legit servers. I think the control file by
> default was in /etc/mail/smfs/smf-grey.conf.
>

Thanks for the reply. However I am not sure I agree. First of all, in
our case, greylisting does a great job with spam. Proven. As for the
specific issue, it is not very easy to except/whitelist domains, since
they are too many. It seems to me that BAD_RCPT_THROTTLE is the one
which has to go. I, however, would welcome some other opinions.

Thanks for your time, anyway.

[Mike Scott]

On 10/10/12 12:48, Aristidis Fesarlis wrote:
...

>>
>
> Thanks for the reply. However I am not sure I agree. First of all, in
> our case, greylisting does a great job with spam. Proven. As for the

It does, and I used to rely on it for my home mail server.
Unfortunately, an increasing number of mainstream ISP's seem to think
RFC-compliance is optional; we were getting an increasing incidence of
black-holed mail, where the sender failed /both/ to retry /and/ to
return to sender. I currently rely on mimedefang/spamassassin plus
milter-regex (using pcre libraries),

> specific issue, it is not very easy to except/whitelist domains, since
> they are too many. It seems to me that BAD_RCPT_THROTTLE is the one
> which has to go. I, however, would welcome some other opinions.

I've got it set to 1. Can't really see why anything else would be useful
(at least, for my setup). BTW, a particular group of regular bad
recipients I accept and route to the spamassassin bayes learning stuff.
Trial basis, but seems to work - probably less useful in a commercial
environment.


--
Mike Scott (unet2 <at> [deletethis] scottsonline.org.uk)
Harlow Essex England

[Aristidis Fesarlis]

> It does, and I used to rely on it for my home mail server.
> Unfortunately, an increasing number of mainstream ISP's seem to think
> RFC-compliance is optional; we were getting an increasing incidence of
> black-holed mail, where the sender failed /both/ to retry /and/ to
> return to sender. I currently rely on mimedefang/spamassassin plus
> milter-regex (using pcre libraries),

Might seem a bit harsh, but non-compliance is their problem, not ours.
They also don't bother doing proper DNS registrations (at least here in
Greece). Reverse record yes, forward record no. Does this mean we should
also disable RDNS checks? I don't think so (See my other thread on this
issue).

> I've got it set to 1. Can't really see why anything else would be useful
> (at least, for my setup). BTW, a particular group of regular bad
> recipients I accept and route to the spamassassin bayes learning stuff.
> Trial basis, but seems to work - probably less useful in a commercial
> environment.

Well, I have confirmed that greylisting is having issues with this
setting. In my opinion, and agreeing with you, it's useful but not
useful enough to keep it on and disable greylisting. After all, having 3
layers of protection seems enough (so far). We use MailScanner+ClamAV,
bayesian filtering, and of course DNSBLs (but via Sendmail, as
MailScanner's DNSBL check is extremely CPU intensive, even though it
provides the ability to enable/disable it on a user basis).