Mailing List Archive

On 01/06/2023 21:37, Julian Bradfield via Exim-users wrote:
> How can this be?

Not being denied by that particular verb, but by some
other one?

Look up the debug facilities in the docs. Trigger on, say,
the third RCPT for a message - that should capture one of
these fairly specifically.

From the debug log, look at the ACL processing sequence.
--
Cheers,
Jeremy


--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On 01/06/2023 21:37, Julian Bradfield via Exim-users wrote:
> In response to the recent RCPT-flooding attacks, I changed my
> acl_check_rcpt verification check to say:
> deny
> domains = +local_domains
> !local_parts = postmaster
> !verify = recipient
> message = Unknown user
> delay = 5s
>
> When I test non-existent addresses with a dummy smtp session using
> exim -bh
> then I see the delay being applied:
>>>> check delay = 5s
>>>> delay modifier requests 5-second delay
>>>> delay skipped in -bh checking mode
>
> However, in the exim log file I'm still seeing 99 denied RCPT commands
> all with the same timestamp.
>
> How can this be?

acl_check_rcpt's deny applies to the RCPT not the connection. This is
like if there is one non-existent recipient in a batch then only that is
denied and the rest are delivered. In your case it tests 99 and denies 99.


--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On 02/06/2023 10:41, James via Exim-users wrote:
> On 01/06/2023 21:37, Julian Bradfield via Exim-users wrote:
>> In response to the recent RCPT-flooding attacks, I changed my
>> acl_check_rcpt verification check to say:
>>    deny
>>     domains = +local_domains
>>     !local_parts = postmaster
>>     !verify = recipient
>>     message = Unknown user
>>     delay = 5s

>> However, in the exim log file I'm still seeing 99 denied RCPT commands
>> all with the same timestamp.
>>
>> How can this be?
>
> acl_check_rcpt's deny applies to the RCPT not the connection.  This is like if there is one non-existent recipient in a batch then only that is denied and the rest are delivered.  In your case it tests 99 and denies 99.

That's missing his point; he's not seeing a delay between log lines
for the denials.
--
Cheers,
Jeremy


--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On 2023-06-01, Julian Bradfield via Exim-users <exim-users@lists.exim.org> wrote:
> In response to the recent RCPT-flooding attacks, I changed my
> acl_check_rcpt verification check to say:
> deny
> domains = +local_domains
> !local_parts = postmaster
> !verify = recipient
> message = Unknown user
> delay = 5s

> However, in the exim log file I'm still seeing 99 denied RCPT commands
> all with the same timestamp.

Having switched on acl debugging at the 70th denied RCPT, what I see
in the logs is:


check delay = 5s
delay modifier requests 5-second delay
delay cancelled by peer close

As far as I can see, this only makes any sense if the attacker has
closed its input stream (exim's output stream) - but then shouldn't
exim get an error when it sends the response? And why would the
attacker close its input stream so it can't see the response? The
attack is not heavy enough to be an effective DoS attack, at least not
for me.

(This is exim-4.94 from Debian 11).

--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On 03/06/2023 17:48, Julian Bradfield via Exim-users wrote:
> Having switched on acl debugging at the 70th denied RCPT, what I see
> in the logs is:
>
>
> check delay = 5s
> delay modifier requests 5-second delay
> delay cancelled by peer close
>
> As far as I can see, this only makes any sense if the attacker has
> closed its input stream (exim's output stream) - but then shouldn't
> exim get an error when it sends the response?

Yes. But you didn't show us that bit.

> And why would the
> attacker close its input stream so it can't see the response?

Because it doesn't really care? It can just pipeline all the
RCPT TO: lines, fire-and-forget.
--
Cheers,
Jeremy


--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On 2023-06-03, Jeremy Harris via Exim-users <exim-users@lists.exim.org> wrote:
> On 03/06/2023 17:48, Julian Bradfield via Exim-users wrote:
>> Having switched on acl debugging at the 70th denied RCPT, what I see
>> in the logs is:
>>
>>
>> check delay = 5s
>> delay modifier requests 5-second delay
>> delay cancelled by peer close
>>
>> As far as I can see, this only makes any sense if the attacker has
>> closed its input stream (exim's output stream) - but then shouldn't
>> exim get an error when it sends the response?
>
> Yes. But you didn't show us that bit.

Because it isn't there.

Here's what's in the main log. (The actual domain is redacted because
it's an address leakage detector which I don't want appearing on the web.)

2023-06-03 17:23:55 SMTP connection from [58.53.131.26] (TCP/IP connection count = 1)
2023-06-03 17:23:56 no host name found for IP address 58.53.131.26
2023-06-03 17:24:06 H=([58.53.131.26]) [58.53.131.26] F=<g4ckp5go0l67ba@1001events.com> rejected RCPT <man@redacted.com>: no such user
[ repeated 90+ times for various localparts ]
2023-06-03 17:24:06 unexpected disconnection while reading SMTP command from ([58.53.131.26]) [58.53.131.26] D=10s

What happens in the debug log after the last acl check is:

SMTP>> 421 london.jcbradfield.org lost input connection
LOG: lost_incoming_connection MAIN
unexpected disconnection while reading SMTP command from ([58.53.131.26]) [58.53.131.26] D=10s

--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On 03/06/2023 18:52, Julian Bradfield via Exim-users wrote:
> What happens in the debug log after the last acl check is:
>
> SMTP>> 421 london.jcbradfield.org lost input connection
> LOG: lost_incoming_connection MAIN
> unexpected disconnection while reading SMTP command from ([58.53.131.26]) [58.53.131.26] D=10s

Good, that's as expected.

> Having switched on acl debugging at the 70th denied RCPT

What made you pick that number?
Did the delay operate as expected for the previous ones?
--
Cheers,
Jeremy


--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

D?a 3. júna 2023 17:52:10 UTC používate? Julian Bradfield via Exim-users <exim-users@lists.exim.org> napísal:

>> Yes. But you didn't show us that bit.
>
>Because it isn't there.

You can use notquit ACL to produce log line on that
case(s), including notquit reason...

But anyway, you cannot expect nice (RFC compliant)
behaviour from abusers, that is not their job...

regards


--
Slavko
https://www.slavino.sk/

--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On 2023-06-03, Jeremy Harris via Exim-users <exim-users@lists.exim.org> wrote:
> On 03/06/2023 18:52, Julian Bradfield via Exim-users wrote:
>> What happens in the debug log after the last acl check is:
>>
>> SMTP>> 421 london.jcbradfield.org lost input connection
>> LOG: lost_incoming_connection MAIN
>> unexpected disconnection while reading SMTP command from ([58.53.131.26]) [58.53.131.26] D=10s
>
> Good, that's as expected.

Why is it expected? Shouldn't exim give up when it loses the outgoing
connection?

>> Having switched on acl debugging at the 70th denied RCPT
>
> What made you pick that number?
> Did the delay operate as expected for the previous ones?

No, I just didn't particularly want a debug log with 100 identical
debugs, and the number is not always 100, just somewhere around.

--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On 03/06/2023 19:15, Julian Bradfield via Exim-users wrote:
> On 2023-06-03, Jeremy Harris via Exim-users <exim-users@lists.exim.org> wrote:
>> On 03/06/2023 18:52, Julian Bradfield via Exim-users wrote:
>>> What happens in the debug log after the last acl check is:
>>>
>>> SMTP>> 421 london.jcbradfield.org lost input connection
>>> LOG: lost_incoming_connection MAIN
>>> unexpected disconnection while reading SMTP command from ([58.53.131.26]) [58.53.131.26] D=10s
>>
>> Good, that's as expected.
>
> Why is it expected? Shouldn't exim give up when it loses the outgoing
> connection?

Which is what is did. It shortcut the delay and
got along to handling the lost connection, which is
I think what you mean by "give up".

But we want to know what happened for the previous
RCPT TO.
--
Cheers,
Jeremy


--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On Sat, 3 Jun 2023, Julian Bradfield via Exim-users wrote:

>
> Here's what's in the main log. (The actual domain is redacted because
> it's an address leakage detector which I don't want appearing on the web.)
>
> 2023-06-03 17:23:55 SMTP connection from [58.53.131.26] (TCP/IP connection count = 1)
> 2023-06-03 17:23:56 no host name found for IP address 58.53.131.26
> 2023-06-03 17:24:06 H=([58.53.131.26]) [58.53.131.26] F=<g4ckp5go0l67ba@1001events.com> rejected RCPT <man@redacted.com>: no such user
> [ repeated 90+ times for various localparts ]
> 2023-06-03 17:24:06 unexpected disconnection while reading SMTP command from ([58.53.131.26]) [58.53.131.26] D=10s
>
> What happens in the debug log after the last acl check is:
>
> SMTP>> 421 london.jcbradfield.org lost input connection
> LOG: lost_incoming_connection MAIN
> unexpected disconnection while reading SMTP command from ([58.53.131.26]) [58.53.131.26] D=10s

If D=10s means what I think it means, we have an active delay,
which is good to see.

If all the recipients are pipelined in one blast,
will the "recipient denied" messages will all be logged before the delay
kicks in, or does exim actually twiddle its thumbs when there is a block
of pipelined data waiting to be read ?

--
Andrew C. Aitchison Kendal, UK
andrew@aitchison.me.uk

--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On 2023-06-03, Jeremy Harris via Exim-users <exim-users@lists.exim.org> wrote:
>>>> SMTP>> 421 london.jcbradfield.org lost input connection
>>>> LOG: lost_incoming_connection MAIN
>>>> unexpected disconnection while reading SMTP command from ([58.53.131.26]) [58.53.131.26] D=10s
>>>
>>> Good, that's as expected.
>>
>> Why is it expected? Shouldn't exim give up when it loses the outgoing
>> connection?
>
> Which is what is did. It shortcut the delay and
> got along to handling the lost connection, which is
> I think what you mean by "give up".
>
> But we want to know what happened for the previous
> RCPT TO.

I showed you. All the previous 90-odd RCPTs (apart from those which
were greylisted rather than denied, because they had valid localparts)
ended with

----------- end verify ------------
message: Unknown user
check delay = 5s
delay modifier requests 5-second delay
delay cancelled by peer close
deny: condition test succeeded in ACL "acl_check_rcpt"
end of ACL "acl_check_rcpt": DENY
SMTP>> 550 Unknown user
LOG: MAIN REJECT
H=([58.53.131.26]) [58.53.131.26] F=<g4ckp5go0l67ba@1001events.com> rejected RCPT <amazon@redacted.com>: no such user


I would expect exim to give up when it first encounters the "peer
close" condition on the outstream, and not wait until it detects
closure of the instream.

Given the behaviour of the attacker, the delay doesn't serve any
useful purpose anyway, but at least exiting on outstream close would
reduce the noise in the log file.

--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On 2023-06-03, Andrew C Aitchison via Exim-users <exim-users@lists.exim.org> wrote:
> If all the recipients are pipelined in one blast,
> will the "recipient denied" messages will all be logged before the delay
> kicks in, or does exim actually twiddle its thumbs when there is a block
> of pipelined data waiting to be read ?

The delay on each recipient is triggered, but then cancelled because
exim's smtp_out connection has been shut down.
The delay is implemented by means of a poll(2) on the outstream,
waiting for POLLRDHUP; so if the outstream is closed by the client,
there is no delay. At this point, I would expect exim to get a send
error when it writes the SMTP response, but it appears not to.

I suppose this is because it received the commands pipelined, and so
sends the responses pipelined without flushing the output.

Nonetheless, I think that a pipeline should be aborted if you already
know that the far end is closed.

(I was slow to understand this, because I hadn't heard of SMTP pipelining
before today:)

--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On 03/06/2023 21:29, Julian Bradfield via Exim-users wrote:
> The delay on each recipient is triggered, but then cancelled because
> exim's smtp_out connection has been shut down.

Thanks - that's the item of info I was missing and
hadn't realised.

Dumping the previously-received input once we've
seen the channel close sounds feasible (I'm unsure
if anything should be specifically logged if we did that)
and would cut down on log noise for your specific case.
I don't think standards say anything about the situation,
but it comes into the realm of self-defence vs. bad actors
IMHO.

If you're seeing these often enough, you could run
a quick check with pipelining disabled to see what they
do then. If you can get a sufficient profile on them
(eg. $sender_host_name not good, or helo verify fails)
you could disable on that basis rather than wholesale
(see "control = no_pipelining" for that).
--
Cheers,
Jeremy


--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

D?a 3. júna 2023 20:29:11 UTC používate? Julian Bradfield via Exim-users <exim-users@lists.exim.org> napísal:

>Nonetheless, I think that a pipeline should be aborted if you already
>know that the far end is closed.

IMO you are confused. That RCPT rejection was logged,
doesn't mean that it was send, and even if, i am sure that
attacker will not receive it.

IMO if exim will not process all received commands and log
rejections, important info can be lost (eg. ratelimits, stats,
etc). Anyway, if you care about output flushing on delays,
there is control option to manage that. IIRC the PIPELINE is
exactly mentioned in its description...

BTW, the RBLs are good not only for rejection, but eg. to
disable PIPELINING for suspicious hosts too...

regards


--
Slavko
https://www.slavino.sk/

--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On 2023-06-03, Jeremy Harris via Exim-users <exim-users@lists.exim.org> wrote:
> On 03/06/2023 21:29, Julian Bradfield via Exim-users wrote:
>> The delay on each recipient is triggered, but then cancelled because
>> exim's smtp_out connection has been shut down.
>
> Thanks - that's the item of info I was missing and
> hadn't realised.
>
> Dumping the previously-received input once we've
> seen the channel close sounds feasible (I'm unsure
> if anything should be specifically logged if we did that)
> and would cut down on log noise for your specific case.
> I don't think standards say anything about the situation,
> but it comes into the realm of self-defence vs. bad actors
> IMHO.

It seems to be ok to discard emails if the sender doesn't wait
for the "250 OK"; Exim has been doing that for decades.
Dropping the input if the output is unwritable seems like an
efficient shortcut to the same result.

--
Jasen.

--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On 2023-06-03, Slavko via Exim-users <exim-users@lists.exim.org> wrote:
> D?a 3. júna 2023 20:29:11 UTC používate? Julian Bradfield via Exim-users <exim-users@lists.exim.org> napísal:
>
>>Nonetheless, I think that a pipeline should be aborted if you already
>>know that the far end is closed.
>
> IMO you are confused. That RCPT rejection was logged,
> doesn't mean that it was send, and even if, i am sure that
> attacker will not receive it.

Exim knows the pipeline is closed because that's what causes the
cancellation of the delays.

> IMO if exim will not process all received commands and log
> rejections, important info can be lost (eg. ratelimits, stats,
> etc). Anyway, if you care about output flushing on delays,
> there is control option to manage that. IIRC the PIPELINE is
> exactly mentioned in its description...

True. Indeed, the docs for delay say that SMTP output is, by default,
flushed before the delay, even in pipelining mode, so now I no longer
understand why exim doesn't detect the closed stream on the first
delay ...

> BTW, the RBLs are good not only for rejection, but eg. to
> disable PIPELINING for suspicious hosts too...

I've never used external blacklists (because I don't trust other
people to make my spam decisions for me), but that would be a harmless
use for them. Thanks for the tip!

--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

> > BTW, the RBLs are good not only for rejection, but eg. to
> > disable PIPELINING for suspicious hosts too...
>
> I've never used external blacklists (because I don't trust other
> people to make my spam decisions for me), but that would be a harmless
> use for them.

Another not too harmful use of some black and white RBLs
is for decision to greylist (for 3 min) or not.

For decision to disable pipelining on incoming connections I use
(I'm not sure whether it works):

pipelining_advertise_hosts = ${if eq{$sender_host_name}{$sender_helo_name}\
{*}{+whitelisted_hosts}}

If you haven't a static local white list then {*}{}}

--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

D?a 4. júna 2023 9:40:25 UTC používate? Julian Bradfield via Exim-users <exim-users@lists.exim.org> napísal:

>True. Indeed, the docs for delay say that SMTP output is, by default,
>flushed before the delay, even in pipelining mode, so now I no longer
>understand why exim doesn't detect the closed stream on the first
>delay ...

IMO question is if it cancel delays only, or cancel sending
response too and only logs ACL result. I don't know, as i
don't speek C, to check sources. Packet capture can
reveal this, but i never meet that.

>I've never used external blacklists (because I don't trust other
>people to make my spam decisions for me), but that would be a harmless
>use for them. Thanks for the tip!

I will try to move your minds even more.

There are different RBLs. Some are more decent, other less
decent, but i agree, that SPAM definition is too broad to rely
on decisions of others. I prefer own checks too.

But then there are RBLs which tracks botnets and/or login
attempts. Have you enough capacity (a lot of servers/
sensors/traps/... across of world) to identify them early?
Or you identify them only after some amount of malicious
attempts?

That are hundreds of thousands compromised PCs, IoTs,
even servers (i mostly mean VPSs "servers", maintained
by users)... Do you really want, to allow all of them to
consume your resources only to reinvert wheel (that it
is some botnet)?

It is not only about SPAM, phishing and other related
attempts. Are you interested to get the same scam
from thousands compromised IPs? How it is useful?
And neverending story of "AUTH used, when not
advertised", etc, etc, ...

It is especially hard to track these bads, as when botnet
has a lot of IPs, they can repeat only after long time, but
still to be too many different IPs daily. And the attackers
doesn't use IPv6 (temporary addresses) yet...

regards


--
Slavko
https://www.slavino.sk/

--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On 2023-06-04, Slavko via Exim-users <exim-users@lists.exim.org> wrote:
> But then there are RBLs which tracks botnets and/or login
> attempts. Have you enough capacity (a lot of servers/
> sensors/traps/... across of world) to identify them early?
> Or you identify them only after some amount of malicious
> attempts?

I identify them after one failed login attempt :)

At present, I block addresses for 1 day, and usually have around 12000
blocked addresses at any one time. One ban every few seconds is not a
significant use of resource.

> It is not only about SPAM, phishing and other related
> attempts. Are you interested to get the same scam
> from thousands compromised IPs? How it is useful?

I'm a small MTA, handling only relatives and one small sports club.
So I'm not a particularly heavy target.

I checked the other day - I reject very little at MTA level, but at
MUA level, my personal mail is about 75% obvious spam (that gets sent
to /dev/null by one of half a dozen simple rules), about 12% less
obvious spam (that goes to my "maybe spam" box), and about 12% ham.
I was actually surprised at the 75% spam level, since I never see it
(and have never had a problem with a false positive).


> It is especially hard to track these bads, as when botnet
> has a lot of IPs, they can repeat only after long time, but
> still to be too many different IPs daily. And the attackers

That's why I operate "one strike and you're out". This is occasionally
annoying when I'm setting up a new device and get the password wrong,
but I can live with that.


--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

D?a 4. júna 2023 13:54:49 UTC používate? Julian Bradfield via
Exim-users <exim-users@lists.exim.org> napísal:

>I'm a small MTA, handling only relatives and one small sports club.
>So I'm not a particularly heavy target.

Perhaps you can be not target of targeted atrack, but...

Have you properly set SPF/DKIM/DMARC and have not bad reputation? Then
you are (or can be) good target. How good target you are, you can
derive from 12 000 blocked IPs daily.

BTW, how many of them repeats every some days?

>That's why I operate "one strike and you're out". This is occasionally
>annoying when I'm setting up a new device and get the password wrong,
>but I can live with that.

Hmm, you can, but what other your users? It doesn't matter how many
users you have...

I meet similar approach some years ago, in job with our email provider.
One of our employee did typo in his mail client password, and whole
company (behind NAT) was blocked... Some time passed until i realized
that, then some time passed until email provider investigated and
solved it, nobody was happy...

That is, where identifying of bad IPs can be important, as you can
relative safe apply one time approach to them and/or block them for
long time, and for others apply less strict rules.

regards

--
Slavko
https://www.slavino.sk

On 2023-06-04, Slavko via Exim-users <exim-users@lists.exim.org> wrote:
> D?a 4. júna 2023 13:54:49 UTC používate? Julian Bradfield via
> Exim-users <exim-users@lists.exim.org> napísal:
>>I'm a small MTA, handling only relatives and one small sports club.
>>So I'm not a particularly heavy target.

> Have you properly set SPF/DKIM/DMARC and have not bad reputation? Then
> you are (or can be) good target. How good target you are, you can
> derive from 12 000 blocked IPs daily.

I don't use DMARC yet, but the rest is in place, and Gmail accepts
mail from me :)

> BTW, how many of them repeats every some days?

Actually, I was wrong - I now blacklist for ten days. I must have
changed it a while ago.

>>That's why I operate "one strike and you're out". This is occasionally
>>annoying when I'm setting up a new device and get the password wrong,
>>but I can live with that.
>
> Hmm, you can, but what other your users? It doesn't matter how many
> users you have...

There are no other users who read mail from me by IMAP - I just
forward to them (which has its own annoyances, but even though I
forward all their spam to gmail, gmail still takes mail from me,
though occasionally throttles).

> I meet similar approach some years ago, in job with our email provider.
> One of our employee did typo in his mail client password, and whole
> company (behind NAT) was blocked... Some time passed until i realized
> that, then some time passed until email provider investigated and
> solved it, nobody was happy...
>
> That is, where identifying of bad IPs can be important, as you can
> relative safe apply one time approach to them and/or block them for
> long time, and for others apply less strict rules.

Yes, if I had users like that, I would take a different approach. (My
users' home and work networks are all whitelisted, so it's only their
mobiles that they might get blocked by accident.)

--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On 2023-06-04, Slavko via Exim-users <exim-users@lists.exim.org> wrote:
> --===============5177538003882154364==
> Content-Type: multipart/signed; boundary="Sig_/UlU3IJ5lalsyNpEcaEewzpE";
> protocol="application/pgp-signature"; micalg=pgp-sha256
>
> --Sig_/UlU3IJ5lalsyNpEcaEewzpE
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
>
> D=C5=88a 4. j=C3=BAna 2023 13:54:49 UTC pou=C5=BE=C3=ADvate=C4=BE Julian Br=
> adfield via
> Exim-users <exim-users@lists.exim.org> nap=C3=ADsal:
>
>>I'm a small MTA, handling only relatives and one small sports club.
>>So I'm not a particularly heavy target.
>
> Perhaps you can be not target of targeted atrack, but...
>
> Have you properly set SPF/DKIM/DMARC and have not bad reputation? Then
> you are (or can be) good target. How good target you are, you can
> derive from 12 000 blocked IPs daily.
>
> BTW, how many of them repeats every some days?
>
>>That's why I operate "one strike and you're out". This is occasionally
>>annoying when I'm setting up a new device and get the password wrong,
>>but I can live with that.
>
> Hmm, you can, but what other your users? It doesn't matter how many
> users you have...
>
> I meet similar approach some years ago, in job with our email provider.
> One of our employee did typo in his mail client password, and whole
> company (behind NAT) was blocked... Some time passed until i realized
> that, then some time passed until email provider investigated and
> solved it, nobody was happy...
>
> That is, where identifying of bad IPs can be important, as you can
> relative safe apply one time approach to them and/or block them for
> long time, and for others apply less strict rules.
>
> regards
>
> --=20
> Slavko
> https://www.slavino.sk

I use a strategy where repeated attempts with the same wrong password
(user-password-hash) are not punished further.

I use an SQL database, but the same thing could by done by using an
inverse ratelimit on a hash of user-password preceeding the ratelimit
on ip-address.

--
Jasen.
???????? ????? ???????

--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

D?a 4. júna 2023 20:08:05 UTC používate? Julian Bradfield via Exim-users <exim-users@lists.exim.org> napísal:

>> BTW, how many of them repeats every some days?

>Actually, I was wrong - I now blacklist for ten days. I must have
>changed it a while ago.

You didn' answer the question: How many of them repeats?
In other words, are these IPs (mostly) always new, or (mostly)
always the same (blocked again and again)?

I ask, because my long time ban reports, that repeats happens
after long time. Today repeat stats shows, that ~50 % of bad
access was blocked by it, the median of repeats is ~25 days,
with average of ~32 days and stdev ~29 days. More than 30 %
of the rest was repeat too and was added to that ban.

At first look, the 30 days repeat is not worth to deal with, but
with large amount of IPs it is still relative high count daily.

regards


--
Slavko
https://www.slavino.sk/

--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/