We are seeing hundreds of log entries like this:
2011-05-18 16:55:36 H=(M6nI9Dhe.com) [95.74.239.102] F=<[email protected]> rejected RCPT <[email protected]>: Sender verify failed
2011-05-18 16:55:44 H=(0j6cYg7.com) [187.90.113.193] F=<[email protected]> rejected RCPT <[email protected]>: Sender verify failed
2011-05-18 16:56:22 H=(FSHXl_K9.com) [187.75.54.229] F=<[email protected]> rejected RCPT <[email protected]>: Sender verify failed
2011-05-18 16:56:48 H=(Z6jI8mgW.com) [89.40.253.34] F=<[email protected]> rejected RCPT <[email protected]>: Sender verify failed
2011-05-18 16:56:55 H=(0H6K1bet.com) [190.194.40.21] F=<[email protected]> rejected RCPT <[email protected]>: Sender verify failed
2011-05-18 16:57:01 H=(C3QHVY.com) [190.71.57.242] F=<[email protected]> rejected RCPT <[email protected]>: Sender verify failed
2011-05-18 16:57:08 H=(0Xyv07jJ.com) [190.49.168.191] F=<[email protected]> rejected RCPT <[email protected]>: Sender verify failed
2011-05-18 17:00:05 H=(03s0M_Gs.com) [186.112.1.35] F=<[email protected]> rejected RCPT <[email protected]>: Sender verify failed
Note: I've exchanged the real targeted address/user with this "[email protected]".
And they are not just going after one email address/user here.
So unlike the other, similar attacks I've seen they are using random, spoofed source IP addresses, thus there is nothing we can block to fend off the attack.
At times exim goes down if the number of failed accesses is high enough, and then of course our hosted customers start complaining.
Now, in the past I've understood that this kind of thing can be mitigated by including "log_selector = -rejected_header" in the exim config, which we have done, but this does not seem to help.
Does anyone have any idea about what we could do as a countermeasure to this?
Thanks.
2011-05-18 16:55:36 H=(M6nI9Dhe.com) [95.74.239.102] F=<[email protected]> rejected RCPT <[email protected]>: Sender verify failed
2011-05-18 16:55:44 H=(0j6cYg7.com) [187.90.113.193] F=<[email protected]> rejected RCPT <[email protected]>: Sender verify failed
2011-05-18 16:56:22 H=(FSHXl_K9.com) [187.75.54.229] F=<[email protected]> rejected RCPT <[email protected]>: Sender verify failed
2011-05-18 16:56:48 H=(Z6jI8mgW.com) [89.40.253.34] F=<[email protected]> rejected RCPT <[email protected]>: Sender verify failed
2011-05-18 16:56:55 H=(0H6K1bet.com) [190.194.40.21] F=<[email protected]> rejected RCPT <[email protected]>: Sender verify failed
2011-05-18 16:57:01 H=(C3QHVY.com) [190.71.57.242] F=<[email protected]> rejected RCPT <[email protected]>: Sender verify failed
2011-05-18 16:57:08 H=(0Xyv07jJ.com) [190.49.168.191] F=<[email protected]> rejected RCPT <[email protected]>: Sender verify failed
2011-05-18 17:00:05 H=(03s0M_Gs.com) [186.112.1.35] F=<[email protected]> rejected RCPT <[email protected]>: Sender verify failed
Note: I've exchanged the real targeted address/user with this "[email protected]".
And they are not just going after one email address/user here.
So unlike the other, similar attacks I've seen they are using random, spoofed source IP addresses, thus there is nothing we can block to fend off the attack.
At times exim goes down if the number of failed accesses is high enough, and then of course our hosted customers start complaining.
Now, in the past I've understood that this kind of thing can be mitigated by including "log_selector = -rejected_header" in the exim config, which we have done, but this does not seem to help.
Does anyone have any idea about what we could do as a countermeasure to this?
Thanks.