Sorry, my bad: posted a patch against my earlier commit, not the
bare upstream release. The one attached now should apply cleanly
to milter-greylist-4.5.12 ;)
Hacky Christmas,
Jim Klimov
2014-12-23 14:30, Jim Klimov \ufffd\ufffd\ufffd\ufffd\ufffd:
> 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
--
+============================================================+
| |
| \ufffd\ufffd\ufffd\ufffd\ufffd\ufffd \ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd, Jim Klimov |
| \ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd \ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd CTO |
| \ufffd\ufffd\ufffd "\ufffd\ufffd\ufffd \ufffd \ufffd\ufffd" JSC COS&HT |
| |
| +7-903-7705859 (cellular) mailto:jimklimov@... |
| CC:admin@...,jimklimov@... |
+============================================================+
| () ascii ribbon campaign - against html mail |
| /\ - against microsoft attachments |
+============================================================+Message
Re: [milter-greylist] HELO not "%d" misfires too often
2014-12-23 by Jim Klimov
Attachments
- No local attachments were found for this message.