I'm running postfix with opendkim. My opendkim milter is running on port 10029. CORRECTION: My opendkim milter is running on a unix socket, and there is a DKIM content filter set up on port 10029.

Just today, I started seeing messages like this appearing in my postfix log ...

2023.11.01 21:29:40 hippo postfix/smtp[29756]: EBBA428F83B: to=<[email protected]>, relay=[]:10029, delay=0.94, delays=0.78/0.01/0.04/0.11, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as B71ED28F83C)

It appears that some people have figured out how to use my opendkim milter as an open relay. Or am I somehow misinterpreting this log message?

My postfix server itself is not an open relay, and smtp can only be initiated via authentication.

If I am correct in guessing that opendkim is being used as an open relay, is this a known problem? Or if I'm totally misunderstanding what's going on, can anyone help me understand what's actually happening with those seemingly relayed messages?

Thank you very much.

UPDATE: Could it be that someone discovered that 10029 is an open port, and that it's possible to misuse DKIM's listening port in order to relay emails?

If so, do I simply need to do the following in order to only enable port 10029 access from localhost? ...

iptables -I INPUT -p tcp --dport 10029 -j DROP
iptables -I INPUT -s -p tcp --dport 10029 -j ACCEPT
  • 1
    Show a configuration. How can we tell by just a single log line? It can be, of course, and that's why it's usually hooked as a MIlter, not as SMTP pass-through, and is listening on an unix socket. Nov 2, 2023 at 3:30
  • Please add more log context, and your configuration.
    – anx
    Nov 2, 2023 at 12:22
  • I already stated that it's hooked as a milter, even in the first sentence of my question text. I'll change it to a unix socket. That will probably fix this. My question is whether or not it can be used as a pass-through, and it's been stated here now that it indeed can be. I will definitely post the entire config later today when I'm back home, even though it seems redundant at this point, given that I now know what seems to be occurring and how to fix it (i.e., can be used as a pass-through, and unix socket instead of TCP socket).
    – HippoMan
    Nov 2, 2023 at 13:53
  • My supposition is correct, but I found a more basic cause for the problem. I posted the fix in my Answer here.
    – HippoMan
    Nov 2, 2023 at 17:44

1 Answer 1


It turns out that the iptables fix indeed corrected my problem, although I had originally posted the commands in the wrong order. Should be this way ...

iptables -I INPUT -s -p tcp --dport 10029 -j ACCEPT
iptables -I INPUT -p tcp --dport 10029 -j DROP

But the more basic problem that I needed solve was as follows:

Long ago I switched from DKIMproxy to opendkim.

My milter setup is already properly using a unix socket for opendkim connectivity, but there was some old, left-over code in master.cf that references DKIMproxy that I forgot to delete, as follows:

smtp.name-of-my-host.net:submission inet n       -       y       -       MAXPROC       smtpd
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
  -o smtpd_etrn_restrictions=reject
  -o receive_override_options=no_address_mappings
  -o smtpd_client_connection_count_limit=CONNLIMIT
  -o syslog_name=postfix/submission
  -o smtpd_recipient_restrictions=
  -o smtpd_reject_unlisted_recipient=no
  -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
######## Code to delete starts here ########
  -o content_filter=dksign:[]:10029
# dkim (listening on 10029, sends to 10030)
dksign    unix  -       -       n       -       5       smtp
  -o smtp_send_xforward_command=yes
  -o smtp_discard_ehlo_keywords=8bitmime,starttls inet  n  -      y       -       10      smtpd
  -o content_filter=
  -o receive_override_options=no_unknown_recipient_checks,no_header_body_checks
  -o smtpd_helo_restrictions=
  -o smtpd_client_restrictions=
  -o smtpd_sender_restrictions=
  -o smtpd_recipient_restrictions=permit_mynetworks,reject
  -o mynetworks=
  -o smtpd_authorized_xforward_hosts=
######## End of code to delete ########

All I needed to do was delete everything from the -o content_filter=dksign:[]:10029 line to the end of the listed code block, and the problem went away.

And, of course, after that, I don't need the iptables commands any more.

The reason I never saw this problem until now is probably that someone must have recently discovered the open 10029 port that had been sitting around since a long time ago.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .