On 1/20/26 4:44 PM, Wietse Venema via Postfix-users wrote:
Jamie McClelland via Postfix-users:
Thank you for the quick response pointing me in a different direction.
Since I've already written the TCP tables program that rate limits how I
want, do you see any problems with this modified approach that uses TCP
Tables?
Postfix transport_maps are used for sender and recipient address
validation, before the SMTP server accept a message.
/etc/postfix/main.cf:
smtpd_recipient_restrictions =
...
check_recipient_mx_address tcp:127.0.0.1:1234
...
check_recipient_mx_access?
Whoops! Yes, I meant check_recipient_mx_access. I've updated the rest of
this message to fix that typo.
Note that the query is made once per recipient, so multi-recipient
messages will result in over-counting.
We generally set default_destination_recipient_limit to 1, so I am
assuming that:
1. an email has two recipients
2. both have the same domain name
3. one lookup returns DUNNO, and will be delivered via the instance that
received it
4. the other returns FILTER smtp:[somewhere.else], so would be delivered
via somehwere.else
Is that correct?
I suppose that the tcp: server maintains counts per domain suffix
(many but not all email hosters have a second-level domain name).
Yes - I'm using the public suffix list to determine the tld plus one for
tracking deliveries to a service, not just a single MX record. It won't
be 100% perfect in all cases, but seems close enough.
>> The TCP Tables program would either respond with:
>
>> * DUNNO (if the program determines that the MX server can handle
>> receiving another message from this IP based on previous lookups)
>
> Actualy, the recent number of requests with the same MX domain suffix.
Right - that is more accurate.
> check_recipient_mx_access[SIC] tries to match an MX hostname (in MX
> record) against the tcp_table, before tries to match its IP address
> (from A or AAAA recored) against the tcp_table. Then it tries the next
> MX hostname, and so on.
>
> The tcp_table should therefore always reply with a 'FOUND' result,
> so that check_recipient_mx_access[SIC] never does any address lookups.
>
> Your tcp_table should not return NOTFOUND because that can result
> in many tcp_table lookups per recipient, like nr of MX rcords plus
> nr of address records for all MX hosts combined.
Yes, I see what you mean. Just to avoid possible confusion, "DUNNO"
counts as a "FOUND" response, right? So as long as I return either a
FILTER or a DUNNO response we should be in good shape?
Thanks again for your help. In case anyone is interested - I've
published the TCP tables program here:
https://gitlab.com/jamie/triptick
jamie
Yes,
warning: access table xxxxxx has entry with lookup table: :
warning: do not specify lookup tables inside SMTPD access maps
warning: define a restriction class and specify its name instead.
Which is exactly what you told me to do in the beginning. So, it doesn't
seem like I can po
_______________________________________________
Postfix-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
