<div dir="ltr">There isn't a whole lot that can be done short of white-listing only allowed originators and recipients.  Most anti-spam services filter out critical non-spam emails along with the spam.<div><br></div><div>What I do for my personal domain is actually forward all my mail, spam and all, to my gmail account and let Google's spam filters deal with it (to the tune of hundreds of spams a day).   And for DragonFlyBSD's domain... we've mostly not using it for email beyond the mailing list server and the mailing list server is essentially white-listed based on the subscriptions.<div><br></div><div>-Matt</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 10, 2020 at 7:36 AM Steffen Nurpmeso <<a href="mailto:steffen@sdaoden.eu">steffen@sdaoden.eu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Pierre Abbat wrote in <3633605.BztBv1gPr2@puma>:<br>
 |My mailserver is being attacked by what looks like a botnet since December \<br>
 |16 <br>
 |at 6:07 (11:07 UTC). Many hosts all over the world are sending mail \<br>
 |purporting <br>
 |to be from many domains all over the world to a few domains in Russia. \<br>
 |Most of <br>
 |the IP addresses are blocked by <a href="http://uceprotect.net" rel="noreferrer" target="_blank">uceprotect.net</a>; a few are blocked by other <br>
 |blocklists. A few are not blocked, but are rejected with "Relay access <br>
 |denied". The messages come at a rate of several per second.<br>
 |<br>
 |There are 133 emails stuck in leaf's mail queue, but they do not appear \<br>
 |to be <br>
 |related to this attack.<br>
<br>
Fwiw, not being an administrator and having had no idea of that<br>
side of the road, i learned to let connections "sleep" for<br>
a while.  This is possible with Postfix, for example.  First i let<br>
them hang, before blacklist lookups.  It reduced those attacks<br>
a little bit.  E.g.,<br>
<br>
  smtpd_relay_restrictions =<br>
      sleep NUMBER,<br>
      reject_invalid_helo_hostname,<br>
      reject_non_fqdn_helo_hostname,<br>
      reject_non_fqdn_sender,<br>
      reject_non_fqdn_recipient,<br>
      sleep NUMBER<br>
<br>
You can set restrictive error counts<br>
<br>
  smtpd_soft_error_limit = 1<br>
  smtpd_hard_error_limit = 1<br>
  smtpd_per_record_deadline = yes<br>
  smtpd_timeout = 21s<br>
<br>
This i did after i have switched to OpenSMTPD for one day.  Like<br>
magic, a few hours after i did, there was one connection, it did<br>
nothing for a few seconds, followed by another one, and then these<br>
two started sending mails like grazy to Taiwenese Yahoo addresses<br>
i think it was.  They then entered a wave of disconnections and<br>
reconnections with other addresses which continued this work.  (My<br>
firewall throttles over time.)  Well, i got a nice information<br>
mail from Yahoo Taiwan i think it was saying that they blocked my<br>
IP temporarily because of the activity.  Blocking had no influence<br>
on the attack itself.  Realizing the OpenSMTPD config error<br>
i fixed that, but their misuse continued, and OpenSMPTD did not<br>
seem to have something like Postfix's _error_limit (my query on<br>
OpenSMTPD bugs/tracker never received an answer), so after<br>
continuously blacklisting the bots' IP addresses i threw away<br>
OpenSMTPD and reinstalled Postfix, with the error_limit reduced<br>
from 3 to 1.  Attack over.<br>
<br>
Having said that, it would be tremendous if servers like Postfix,<br>
dovecot, ssh, would offer hooks which would get invoked on<br>
connection establishment and break, to be able to track<br>
un/successful logins as well as "nonsense connections" etc. so<br>
that the entire [di]notify/log file parse sauce could vanish.<br>
Always strived me being total nonsense that log files are parsed<br>
to collect the info that servers had at hand.  Christos Zoulas of<br>
NetBSD implemented the blacklistd with patches for i think at<br>
least Postfix and ssh, this does implement that for logins at<br>
least.  FreeBSD imported that.<br>
<br>
Of course all that does not help against firewall rules aka tables<br>
filling with lots of addresses to be blocked.  I have some general<br>
rate limiting, but sometimes this bites real connectivity, for<br>
example if people merge their readily prepared git topic branches<br>
into mainline repositories, and dozen of messages from the same<br>
server fly in.  I have no idea on what to do against these two<br>
problems.<br>
<br>
--steffen<br>
|<br>
|Der Kragenbaer,                The moon bear,<br>
|der holt sich munter           he cheerfully and one by one<br>
|einen nach dem anderen runter  wa.ks himself off<br>
|(By Robert Gernhardt)<br>
</blockquote></div>