On 9/9/2019 7:16 AM, Jan Ingvoldstad via Exim-users wrote:
> I've had another variant for years:
>
> acl_check_mail:
> deny
> message = no HELO given before MAIL command
> condition = ${if def:sender_helo_name {no}{yes}}
> delay = 60s
>
> The delay is a nice touch, if you have the TCP connections to spare.
>
> Jan
>
> On Mon, Sep 9, 2019 at 4:10 PM Phillip Carroll via Exim-users <
> exim-users@???> wrote:
>
>> my configuration has had something similar for years. Is there any
>> significant difference?
>>
>> acl_check_mail:
>> # deny any mail without helo name
>> deny message = HELO required before MAIL
>> condition = ${if eq{$sender_helo_name}{} {1}}
>>
>> (Yours obviously simpler to read)
>>
>> On 9/6/2019 6:16 PM, Phil Pennock via Exim-users wrote:
>>> On 2019-09-06 at 22:04 +0200, Heiko Schlittermann via Exim-users wrote:
>>>> The HELO ACL doesn't help either, as the first EHLO comes before
>>>> STARTTLS, and the second EHLO doesn't have to come, the client may send
>>>
>>> Oh pox. My memory is going. I hadn't realized that my protection
>>> against this comes from long-standing local configuration, not Exim
>>> defaulting to enforcing this:
>>>
>>> acl_check_mail:
>>> deny message = 503 Bad sequence of commands - must send
>> HELO/EHLO first
>>> condition = ${if !def:sender_helo_name}
>>>
>>> If anyone wants to protect against stupidity: I've been using that guard
>>> for "longer than the five years that the current mail-server is running"
>>> and I'm not going diving through git history to find when it was
>>> introduced to my older server.
>>>
>>> To the best of my knowledge, that has never blocked legitimate mail.
>>> Everyone does EHLO after STARTTLS.
>>>
>>> Exim drops pre-TLS sender_helo_name after negotiating TLS. This is
>>> required by RFC 3207 (section 4.2) but not explicitly mentioned in the
>>> Exim Spec, AFAICT.
>>>
>>> -Phil
>>>
>>
>> --
>> ## List details at https://lists.exim.org/mailman/listinfo/exim-users
>> ## Exim details at http://www.exim.org/
>> ## Please use the Wiki with this list - http://wiki.exim.org/
>>
>
>
I don't think a delay would matter much. My server is not very
busy---average 1500 or so entries in main log daily. The vast majority
of my site's rejections are due to spamhaus lookups. (A hundred or so daily)
My archived logs go back four years. I just did a full archive search on
the deny message I posted a little earlier. ("HELO required before MAIL")
Over those 4 years, the server has logged that message a total of only 7
times, on 3 separate dates. The first 3 instances were logged on a total
of two dates in 2017. The remaining 4 were on June 27 this year, by a
Latvian host. I conclude this is not a very frequent attack mode.
The Latvian host's attempts are sort of interesting:
My configuration has a later check in acl_check_mail that requires HELO
to match the host unless/until whitelisted. It does a temporary
rejection on a mismatch. (Being small lets me use somewhat drastic
measures. I check the log daily for these and either blacklist or
whitelist the host in that trap. Legitimate hosts keep retrying for days. )
The Latvian host initially was trying to make connection appear to come
from my server. The sequence:
(1) The first attempt was rejected by the HELO/host mismatch. (HELO sent
was "localhost")
(2) A few milliseconds later, a second attempt got the same rejection
due to mismatch. (This time HELO was my own domain)
(3) A half-hour later, there were two concurrent connections that were
lost after about 5 seconds each, because no mail was sent. No idea what
was in those SMTP dialogs. (I don't see an explicit timeout that length
in the .conf. Is that a default timeout?
(4) Seven minutes later, same attempt as (3) lost due to no mail after
several seconds.
(5) Six minutes after (4):
"rejected HELO ... syntactically invalid argument(s): (no argument
given)"; immediately followed by the empty HELO rejection in
acl_check_mail.
This was repeated a minute later, then twice more 50 minutes after that,
for a total of four times with no HELO - proceed directly to mail.
The following day, there was another attempt using the localhost and my
domain. They then gave up.
Phil Carroll
