Hi Wietse! Thanks for your quick response.
Of course, I'm aware that smtpd cannot sent mail - I was just a little bit imprecise there. I should have said: "An smtpd which receives the mail from internal systems for sending out to the internet" :) I found a wiki entry about a hold transport, but when I look now back at that, it specified "defer_transports = hold" - and I had assumed it meant that there was a hold transport (which would be neat anyway ;) ) And when I put the things together for this mail, I suddenly realized that the smtpd with proxy_filter could not really have access to a HOLD action, as it needs to go through the proxy before. But I wasn't sure - and the logging is a bit convoluted here, so I didn't see the warning there. Thanks very much for the reply, I know now which levers to pull to get what I need! Jens On Fri, Sep 13, 2024 at 2:22 PM Wietse Venema <wie...@porcupine.org> wrote: > > Jens Hoffrichter via Postfix-users: > > Hi! > > > > We are running a pretty big postfix installation for a big corporate > > customer. > > > > Next week, there are migrations in the backend for some mailboxes, and > > the inbound mail for these mailboxes should be put on hold on the > > postfix directly before it is being sent to Exchange. > > > > I was under the impression that I could either put the mailboxes > > directly in a transport table, with a hold: transport - but that > > results in "transport not found - deferred". > > Impression based on what? There is a 'hold' queue, but no such > thing as a 'hold' transport. > > You can destine messages to the 'hold' queue with an action in an > access table, header_checks, body_chgecks, or Milter quarantine > action. > > > The other thing I found was to put it in a recipient_access map with > > HOLD as the pattern, but that just gets ignored. > > Then you made a mistake, see below. > > > We have two different smtpd configurations on that server, one which > > receives the mail from the internet with spam checks etc, and one > > which sends out the mail to the internet. > > FYI, smtpd can only receive email. > > > We have the following recipient restrictions class in our main.cf: > > > > internet_inbound_recipient_restrictions = > > check_recipient_access > > hash:/mail/postfix/etc/postfix/maps/recipientchecks_inbound.manual-gateway > > check_recipient_access > > hash:/mail/postfix/etc/postfix/maps/recipientchecks_inbound.auto-gateway > > check_recipient_access > > ldap:/mail/postfix/etc/postfix/ldap/recipientchecks_inbound.cf > > reject > > > > The master.cf entry for the internet inbound mail service looks like this > > 84.x.x.x:25 inet n - y - 120 smtpd > > -o smtpd_proxy_filter=127.0.0.1:10035 > > -o smtpd_banner=$smtpd_internet_banner > > -o > > smtpd_recipient_restrictions=internet_inbound_recipient_restrictions > > -o smtpd_sender_restrictions=internet_inbound_sender_restrictions > > -o smtpd_client_restrictions=internet_inbound_client_restrictions > > -o smtpd_relay_restrictions=reject_unauth_destination > > -o syslog_name=smtpd_internet > > > > But the HOLD for an email address just gets ignored. > > You are ignoring Postfix warnings at your peril. > > "access table %s: with smtpd_proxy_filter specified, action %s is > unavailable", > > You need to 'hold' after the smtpd_proxy_filter. > > Wietse _______________________________________________ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
