Yahoo Groups archive

Milter-greylist

Index last updated: 2026-04-28 23:32 UTC

Message

Re: [milter-greylist] HELO not "%d" misfires too often

2014-12-23 by Jim Klimov

EHLO all,

Better late than never, they say... got a bit of quiet time late
in the year and finally took a look at the problem with misfiring
`not helo "%d"` clauses. Well, the case-sensitivity was just a rare
tip of the iceberg - thanks to my other rules, this one was not
often evaluated, although enough to cause a raised eyebrow when
some legitimate-looking relay was greylisted due to a mismatch with
seemingly identical HELO and DNSPTR names.

Guess what?

The "%d" was tested (and mis-matched) literally.

Patch attached to call format string expansion (any defined format)
in the helo_strstr clause. And case-insensitivity while we are at it.

This is being tested for the last night on our relay, seems working
as expected now.

HTH,
Jim Klimov


2014-08-29 12:54, Jim Klimov jimklimov@... [milter-greylist] wrote:
> A while ago I was suggested to use 'helo not "%d"' constructs
> to verify if DNS PTR and HELO names of a remote relay agree.
> Unfortunately, either I do something wrong, or it misfires
> too often. With a config snippet like this:
>
> racl continue \
> not helo "%d" \
> set $dnsscore+=10 \
> log "(%i SP:+10) %P{conninfo}: Malformed HELO (HELO '%h' does not
> match reverse DNS '%d')" \
> set $msgDNS="Malformed HELO (HELO '%h' does not match reverse DNS
> '%d')"
>
> ... I often see logs like these, which (seem to) mention the
> same string in both HELO and DNSPTR parts:
>
> Aug 29 01:06:14 dao.virt.cos.ru milter-greylist: [ID 536703 mail.info]
> (216.227.218.80 SP:+10) IP:'216.227.218.80' DOMAIN:'joy.lunarbreeze.com'
> HELO:'joy.lunarbreeze.com' FROM:'gVIwyErHMkoOi@...'
> RCPT:'bugaev@...': Malformed HELO (HELO 'joy.lunarbreeze.com' does
> not match reverse DNS 'joy.lunarbreeze.com')
>
> ...and I can't find any mismatches in real DNS (perhaps dot-ended
> names, etc.) Any ideas on debugging this issue?
> NOTE: Okay, the example above is a spammer example, but I have
> such issues with big-name providers as well which are unlikely to
> be lax in their DNS setups. Their logs rolled off-screen at the
> moment ;(
>
> ..These are possibly more reasonable "mismatches", as far as
> case-sensitivity might be concerned (although not really
> relevant for DNS):
>
> Aug 29 04:57:51 dao sendmail[19426]: [ID 801593 mail.notice]
> s7O0vmQv019426: MGL-TEMPFAIL-DNS-120: DNScheck: likely spam-source;
> repost from registered SMTP server, or contact
> bypass-antispam@.... Malformed HELO (HELO
> 'DUB004-OMC1S3.hotmail.com' does not match reverse DNS
> 'dub004-omc1s3.hotmail.com') SPF pass
>
> ...And these are proper hits that the rule is made for:
>
> Aug 29 00:38:09 relay-mta milter-greylist: [ID 354941 mail.info]
> (89.240.10.108 SP:+10) IP:'89.240.10.108'
> DOMAIN:'host-89-240-10-108.static.as13285.net'
> HELO:'mail.netcellsolutions.com' FROM:'gzivhsom@...'
> RCPT:'hel@...': Malformed HELO (HELO 'mail.netcellsolutions.com' does
> not match reverse DNS 'host-89-240-10-108.static.as13285.net')
>
> Thanks,
> Jim Klimov

Attachments

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.