Trying to add custom header to messages from a given cloud provider

[Matthew Selsky]

Hi all,

I'm using multi-instance postfix and I want to relay messages from a given CIDR block at a cloud provider, and I want to add a custom header.

I have this in main.cf:
cidr = cidr:${config_directory}/
smtpd_recipient_restrictions =
    reject_non_fqdn_recipient
    reject_unknown_recipient_domain
smtpd_relay_restrictions =
  permit_mynetworks
  check_client_access ${cidr}tag-cloud-email-providers.cidr
  permit_tls_clientcerts
  reject

tag-cloud-email-providers.cidr contains:
[...]
209.85.128.0/17 PREPEND X-Gmail-Tenant: TRUE
[...]

syslog has:
2020-12-21T23:35:38.737+00:00 customer.example.com postfix-mta-in/smtpd[2984727]: NOQUEUE: reject: RCPT from mail-ot1-f70.google.com[209.85.210.70]: 554 5.7.1 <[hidden email]>: Recipient address rejected: Access denied; from=<[hidden email]> to=<[hidden email]> proto=ESMTP helo=<mail-ot1-f70.google.com>​

postmap queries seem reasonable:
$ postmap -q 209.85.210.70 cidr:/etc/postfix-mta-in/tag-cloud-email-providers.cidr; echo $?
PREPEND X-Gmail-Tenant: TRUE​

My very gently sanitized "postconf -n" output is attached.


Thanks,
-Matt

[Wietse Venema]

Matthew Selsky:

> smtpd_relay_restrictions =
>   permit_mynetworks
>   check_client_access ${cidr}tag-cloud-email-providers.cidr
>   permit_tls_clientcerts
>   reject
>
> tag-cloud-email-providers.cidr contains:
> [...]
> 209.85.128.0/17 PREPEND X-Gmail-Tenant: TRUE
> [...]

The above allows a recipient only it it satisfies permit_mynetworks
or permit_tls_clientcerts.

Perhaps you can try this:

smtpd_relay_restrictions =
    permit_mynetworks
    check_client_access ${cidr}tag-cloud-email-providers.cidr
    permit_tls_clientcerts
    reject_unauth_destination

That will permit mail that your system is primary MX for.

Note that there is an implicit 'permit' at the end.

        Wietse

[Viktor Dukhovni]

On Tue, Dec 22, 2020 at 12:27:13AM +0000, Matthew Selsky wrote:

> I'm using multi-instance postfix and I want to relay messages from a
> given CIDR block at a cloud provider, and I want to add a custom
> header.
>
> I have this in main.cf:

> cidr = cidr:${config_directory}/
> smtpd_recipient_restrictions =
>     reject_non_fqdn_recipient
>     reject_unknown_recipient_domain
>
> smtpd_relay_restrictions =
>   permit_mynetworks
>   check_client_access ${cidr}tag-cloud-email-providers.cidr
>   permit_tls_clientcerts
>   reject

You should probably only do the relay check in relay restrictions, and
then *again* match the CIDR block in recipient restrictions, where you
implement the PREPEND action.  Assuming I've understood your question
correctly.  The data provided is quite thorough, but the message is
a bit light on what you're not succeeding in doing...

> tag-cloud-email-providers.cidr contains:
> [...]
> 209.85.128.0/17 PREPEND X-Gmail-Tenant: TRUE
> [...]
>
> syslog has:
> 2020-12-21T23:35:38.737+00:00 customer.example.com
> postfix-mta-in/smtpd[2984727]: NOQUEUE: reject: RCPT from
> mail-ot1-f70.google.com[209.85.210.70]: 554 5.7.1 <[hidden email]>:
> Recipient address rejected: Access denied;
> from=<[hidden email]> to=<[hidden email]> proto=ESMTP
> helo=<mail-ot1-f70.google.com>
>
> postmap queries seem reasonable:
> $ postmap -q 209.85.210.70 cidr:/etc/postfix-mta-in/tag-cloud-email-providers.cidr; echo $?
> PREPEND X-Gmail-Tenant: TRUE

--
    Viktor.

[Matthew Selsky]

Hi Viktor!

On Mon, Dec 21, 2020 at 07:52:49PM -0500, Viktor Dukhovni wrote:

> On Tue, Dec 22, 2020 at 12:27:13AM +0000, Matthew Selsky wrote:
>
> > I'm using multi-instance postfix and I want to relay messages from a
> > given CIDR block at a cloud provider, and I want to add a custom
> > header.
> >
> > I have this in main.cf:
>
> > cidr = cidr:${config_directory}/
> > smtpd_recipient_restrictions =
> >     reject_non_fqdn_recipient
> >     reject_unknown_recipient_domain
> >
> > smtpd_relay_restrictions =
> >   permit_mynetworks
> >   check_client_access ${cidr}tag-cloud-email-providers.cidr
> >   permit_tls_clientcerts
> >   reject
>
> You should probably only do the relay check in relay restrictions, and
> then *again* match the CIDR block in recipient restrictions, where you
> implement the PREPEND action.  Assuming I've understood your question
> correctly.  The data provided is quite thorough, but the message is
> a bit light on what you're not succeeding in doing...

I want to allow the Cloud provider to be able to relay all email through postfix.

Our setup is:

cloud provider -> postfix gateway -> internet

I want to add a header to the messages from this cloud provider so that I can do additional checks in other postfix instances.

The problem that I currently face is that the messages are rejected with "Recipient address rejected: Access denied;" when I want them to be relayed instead.

Is this what I need to accomplish that?

cidr = cidr:${config_directory}/
smtpd_recipient_restrictions =
  reject_non_fqdn_recipient
  reject_unknown_recipient_domain
  check_client_access ${cidr}tag-cloud-email-providers.cidr
smtpd_relay_restrictions =
  permit_mynetworks
  check_client_access ${cidr}cloud-email-providers.cidr
  permit_tls_clientcerts

Where tag-cloud-email-providers.cidr has:
209.85.128.0/17 PREPEND X-TS-Gm-Tenant: TRUE

And cloud-email-providers.cidr has:
209.85.128.0/17 OK

Or do I need to add the cloud providers blocks to mynetworks for any reason?


Thanks,
-Matt

[Viktor Dukhovni]

On Tue, Dec 22, 2020 at 03:23:56AM +0000, Matthew Selsky wrote:

> I want to allow the Cloud provider to be able to relay all email through postfix.
>
> Our setup is:
>
> cloud provider -> postfix gateway -> internet
>
> I want to add a header to the messages from this cloud provider so
> that I can do additional checks in other postfix instances.
>
> The problem that I currently face is that the messages are rejected
> with "Recipient address rejected: Access denied;" when I want them to
> be relayed instead.
>
> Is this what I need to accomplish that?
>
> cidr = cidr:${config_directory}/
> smtpd_recipient_restrictions =
>   reject_non_fqdn_recipient
>   reject_unknown_recipient_domain
>   check_client_access ${cidr}tag-cloud-email-providers.cidr

Yes, this will tag any message that is ultimately accepted.

> smtpd_relay_restrictions =
>   permit_mynetworks
>   check_client_access ${cidr}cloud-email-providers.cidr
>   permit_tls_clientcerts

Yes, this will permit relay access for the matching IPs.

> Where tag-cloud-email-providers.cidr has:
> 209.85.128.0/17 PREPEND X-TS-Gm-Tenant: TRUE
>
> And cloud-email-providers.cidr has:
> 209.85.128.0/17 OK
>
> Or do I need to add the cloud providers blocks to mynetworks for any reason?

No, you can leave mynetworks unchanged if there is more to mynetworks
than mere relay access.

--
    Viktor.

[Matthew Selsky]

Hi Viktor,

On Mon, Dec 21, 2020 at 11:20:30PM -0500, Viktor Dukhovni wrote:

> On Tue, Dec 22, 2020 at 03:23:56AM +0000, Matthew Selsky wrote:
>
> > cidr = cidr:${config_directory}/
> > smtpd_recipient_restrictions =
> >   reject_non_fqdn_recipient
> >   reject_unknown_recipient_domain
> >   check_client_access ${cidr}tag-cloud-email-providers.cidr
>
> Yes, this will tag any message that is ultimately accepted.
>
> > smtpd_relay_restrictions =
> >   permit_mynetworks
> >   check_client_access ${cidr}cloud-email-providers.cidr
> >   permit_tls_clientcerts
>
> Yes, this will permit relay access for the matching IPs.

Thanks, this worked perfectly!

> No, you can leave mynetworks unchanged if there is more to mynetworks
> than mere relay access.

Is there any reason not to merge ${cidr}cloud-email-providers.cidr into mynetworks?  I only reference mynetworks in the following places currently:

smtpd_helo_restrictions =
  permit_mynetworks
  reject_invalid_helo_hostname
  reject_non_fqdn_helo_hostname
smtpd_relay_restrictions =
  permit_mynetworks
  check_client_access ${cidr}cloud-email-providers.cidr
  permit_tls_clientcerts reject

If I add ${cidr}cloud-email-providers.cidr to mynetworks, then they'd pick up the relaxed restrictions for smtpd_helo_restrictions, so this seems reasonable and allows me to maintain 1 fewer table.  Is there anything that I'm missing?


Thanks,
-Matt

[Viktor Dukhovni]

On Thu, Dec 24, 2020 at 01:13:05AM +0000, Matthew Selsky wrote:

> > No, you can leave mynetworks unchanged if there is more to mynetworks
> > than mere relay access.
>
> Is there any reason not to merge ${cidr}cloud-email-providers.cidr into mynetworks?  I only reference mynetworks in the following places currently:
>
> smtpd_helo_restrictions =
>   permit_mynetworks
>   reject_invalid_helo_hostname
>   reject_non_fqdn_helo_hostname
> smtpd_relay_restrictions =
>   permit_mynetworks
>   check_client_access ${cidr}cloud-email-providers.cidr
>   permit_tls_clientcerts reject
>
> If I add ${cidr}cloud-email-providers.cidr to mynetworks, then they'd
> pick up the relaxed restrictions for smtpd_helo_restrictions, so this
> seems reasonable and allows me to maintain 1 fewer table.  Is there
> anything that I'm missing?

The parameters that reference $mynetworks in a non-trivial way by
default are:

    postscreen_access_list
    smtpd_client_event_limit_exceptions
    smtpd_relay_restrictions

If you're OK with including the guilty parties in all three cases, then
sure, you can simply list them in mynetworks.

--
    Viktor.