Milter vs. *_restrictions: evaluation order

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Milter vs. *_restrictions: evaluation order

Vincent Pelletier-2
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


Reply | Threaded
Open this post in threaded view
|

Re: Milter vs. *_restrictions: evaluation order

PGNet Dev
fwiw, shared here long ago -- don't remember the origin

Restrictions execution order:

postscreen, smtpd_mumble_restrictions, milter SMTP command inspection,
smtpd_proxy_filter, header/body_checks, milter header/body inspection,
content_filter