0

I'm running postfix 2.11.3 under Debian.

I have installed a homegrown milter which runs in conjunction with CONNECTION, HELO, MAIL FROM, RCPT TO, HEADERS, and EOM, and it's been working well for years. It uses the standard milter API.

When the sender specifies a syntactically incorrect address, I see errors like the following coming from postfix (where xxx.xxx.xxx.xxx represents the IP address of the sender):

postfix/smtpd[29109]: warning: Illegal address syntax from example.com[xxx.xxx.xxx.xxx] in MAIL command: <unparseable-item@example.com>
postfix/smtpd[29109]: disconnect from example.com[xxx.xxx.xxx.xxx]

At this point, postfix terminates the connection, but I'm wondering whether there might be a way for the milter to know about this warning and respond to it.

Can the connection be maintained after such an error, perhaps? If so, I could then have the milter trigger the disconnection after processing the error.

Thank you in advance for any ideas and suggestions.

HippoMan
  • 222
  • 1
  • 10
  • Postfix alone is able to detect and get rid of the problem, fast and reliable, why you want to involve anything else? Why do you want to maintain a connection with the peer which is clearly breaking the rules? What good you are expecting from such a peer? – Nikita Kipriyanov May 18 '23 at 17:56
  • I want to log the sender's email address and IP address in a database I am keeping of various incorrect email connection attempts. – HippoMan May 18 '23 at 18:05
  • You have an IP address. As for email address, again, you will gain nothing knowing it. When spammers send mail the freely fake sender addresses, so most often those addresses are innocent victims. Also notice, it says *wrong address syntax*, what means some garbage went in the place of address that moment. Garbage is even less valuable. // All in all that's strange, I've working with Postfix for 15+ years and maintained a handful of instances overall, but I struggle to remember the "invalid address syntax" message. – Nikita Kipriyanov May 19 '23 at 03:30
  • Also I don't get why "milter" if you need to log. – Nikita Kipriyanov May 19 '23 at 03:34
  • I already use my milter for logging other similar events that it is able to respond to. I prefer to re-use my already written software for this than to write something new ... if would be possible to send the info about these particular warnings to my milter. But since that doesn't seem possible, I might just have to write the other software, after all. And in visually examining my logs, I see that the IP address is indeed being re-used in some instances. In any case, thank you for your replies. – HippoMan May 19 '23 at 13:21
  • 1
    This is wrong preposition. The primary in Internet is: reject as early as possible, use least amount or system resources that is possible. For example consider operation under DDoS: if you send all to heavy milter, you'll much more likely be overloaded. And in this case Postfix provides you with the capability to reject without even touching a database etc., just by analyzing the validity of the address. Wonderful, and thank Wietse for this! – Nikita Kipriyanov May 19 '23 at 13:27
  • 1
    by the way, postfix 2.11.3 is what Debian? Consider upgrading; current has 3.5.17 – Nikita Kipriyanov May 20 '23 at 14:12

1 Answers1

0

You can do it the other way around: unconditionally place all connections and all successful deliveries into a suitable (e.g. SQL) log. You can then (not necessarily synchronous with ongoing SMTP sessions) filter your log for connections that failed to deliver to at least one recipient. Because there is not much difference between clients that disconnect cleanly, clients that fail to continue after initial greeting, clients that send garbage and submissions eventually rejected by local policy. You can treat them all the same.

That being said.. Before you roll out any complex (and thus introducing new edge cases and undesirable error states) mechanism, consider merely capping the number of active connections per IP prefix with a simple firewall rule. Reduce the effect of misbehaving clients to tolerable levels and then just stop caring about what little cycles they waste, so long as they do not waste admin time.

anx
  • 8,963
  • 5
  • 24
  • 48