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
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 = re
Having done this and looking at all the timestamps that appear in the trace log
relative to the exim mainlog I think I can safely conclude that these emails
never make their way to my filter. since none of the timestamps are lining up
for the offending emails when they are processed.
> On Jun 1
> On Jun 1, 2023, at 7:31 AM, Andrew C Aitchison wrote:
>
> On Wed, 31 May 2023, Robert Nicholson wrote:
>
>> So this issue hasn’t resolved itself unfortunately and so I still get the
>> occasional email that just simply fails to deliver.
>>
>> Does anybody have any more ideas as to how I in
On Fri, Jun 02, 2023 at 09:56:16AM -0500, Robert Nicholson via Exim-users wrote:
> Having done this and looking at all the timestamps that appear in
> the trace log relative to the exim mainlog I think I can safely
> conclude that these emails never make their way to my filter. since
> none of the
On Fri, Jun 02, 2023 at 03:20:45PM -0500, Robert Nicholson via Exim-users wrote:
> So the following .forward works
...
> This is the one that breaks still.
Well, it gives a straitforward way to locate point of failure.
The logwrite statement should help to reduce number of steps.
--
Eugene Ber
