Hello,
I have a private (firewalled) outgoing-emails-only setup with main.cf
containing (among others):
smtpd_recipient_restrictions =
reject_non_fqdn_recipient
reject_unknown_recipient_domain
permit_sasl_authenticated
reject
smtpd_milters =
[some local ip:port]
The (only) milter used replaces all recipients with a single,
hard-coded email address. The use is a production clone setup for an
application which sends emails. Production database contains real email
addresses to which we do not want to send any email from the clone
setup. This setup seems to work well.
The reason I'm posting is that one "real" address contained a
non-existent domain. reject_unknown_recipient_domain did its job and
postfix rejected the email, despite that recipient address not being
relevant in practice thanks to the milter.
I have no problem with this behaviour (nor would I have a problem if it
were the other way around), but it showed me that I did not completely
understand how this works. So it made me wonder:
- What is the restritions vs. milter evaluation order ?
I could not find it in the documentation: MILTER_README does not
mention restrictions, SMTPD_ACCESS_README does not mention milters,
and (5)postconf does not specify an order on either option (although I
could have missed it if it was on a related option, as of course this
page contains a lot of matches for both). (8)smtpd documents milters
in a "BEFORE QUEUE MILTER CONTROLS" section, but AFAIK milters are
involed during the smtp transaction just as the restrictions are, so
I don't think this is giving any fine-grained information on
execution order.
- Is reject_unknown_recipient_domain checked again after milter
rewrite ? Although in my setup the final destination is hard-coded
and sender would get errors which are not its own fault, I could
imagine milters doing some address transformations based on original
RCPT-TO, and rejecting the email could maybe be legitimate if it
leads to a bogus value.
Am I missing a place where this is documented ?
Is it a small-enough implementation detail that it does not justify
documenting it (which would be perfectly fine for me) ?
Regards,
--
Vincent Pelletier
ERP5 - open source ERP/CRM for flexible enterprises
