Re: Need help with smtp_tls_policy_maps settings.
On 19/2/22 00:19, Wietse Venema wrote: I meant net/mask. For examples, see https://www.postfix.org/cidr_table.5.html Wietse Thank you for the link. Saved me much time. P.V.Anthony
Re: Need help with smtp_tls_policy_maps settings.
On 18/2/22 22:07, Noel Jones wrote: No. The docs say the table is not searched by hostname — Noel Jones Noted. Thank you for the reply. P.V.Anthony
Re: canonical_maps vs. *_recipient_maps
Demi Marie Obenour: Checking application/pgp-signature: FAILURE -- Start of PGP signed section. > On 2/18/22 12:20, Wietse Venema wrote: > > Jaroslaw Rafa: > >> Dnia 18.02.2022 o godz. 11:17:13 Wietse Venema pisze: > >>> Starting to wonder if reject_unverified_recipient should be given > >>> more publicity. > >> > >> Definitely should. I always thought of reject_unverified_recipient only in > >> context of a front-end server relaying mail to the final server, which is a > >> pretty rare case for me (I usually work with single-server setups). I did > >> not think that it can be used in such context as rewriting by canonical > >> maps. > > > > Upon closer reading, address verification has limits some of > > which are intentional. > > > > Address verification will validate addresses that result from > > canonical mappings and of 1-to-1 virtual aliases. > > > > Address verification will not validate addresses that result from > > the expansion of 1-to-many virtual aliases. It will just report > > that the address before alias expansion is valid. > > > > It does not validate 1-to-many expansions because that would result > > in an explosive behavior, because the result would ambiguous if > > some addresses in the expansion result are valid and some not, and > > because it could be undesirable to reveal what 1-to-many aliases > > expand into. > > > > Address verification will also not validate addresses that result > > from local aliasing/forwarding with alias_maps or ~/.forward files, > > because I was too lazy to write code that determines if these are > > 1-to-1 or 1-to-many, but also because it might reveal too much > > information. It will just report that the address before alias > > expansion or forwarding is valid. > > Is reject_unverified_recipient the correct approach for a standard > Postfix/Dovecot setup? Probably. I do not use Dovecot myself. Address verification adds a bit of aditional load, but Postfix has a safety mechanism to limit the number of address verification probes that can be in flight at the same time (it will reply with SMTP code 4XX for excess requests). Wietse
SPF and policyd
Hi, I'm using the SPF policyd service recommended here some time ago.
I hoped I could ask some questions about how it works since it doesn't
appear to have any other direct support avenues available.
I'm trying to understand the following log entry:
Feb 20 10:01:59 armor policyd-spf[2466782]: prepend X-Comment: SPF
skipped for whitelisted relay domain - client-ip=168.245.99.219;
helo=o25.sg.marketing.agoda.global;
envelope-from=bounces+8548506-62a0-05448=hotel.example.com@marketing.agoda.global;
receiver=
None of the IPs or domains listed above are in my local whitelist, but
the IP is listed in the SPF record for marketing.agoda.global. Is that
what it is referring to? I tried tracing the code, but I'm not much of
a python programmer.
It appears to check the SPF record for the domain in the whitelist,
not the sending domain. bypass_list_list is the whitelist entries in
my config.
for domain in bypass_list_list:
res = spf.check2(ip, domain, domain,
querytime=configData.get('Whitelist_Lookup_Time'))
if domain_res[0] == 'Pass':
...
and if it results in "Pass", then it returns True if the domain in the
whitelist entry, not the sending domain?
Here's how I have it set up:
policy-spf unix - n n - - spawn
user=nobody argv=/usr/libexec/postfix/policyd-spf
And the relevant info from my policyd-spf.conf:
skip_addresses =
139.138.56.0/24,127.0.0.0/8,209.216.90.0/24,:::127.0.0.0/104,::1,52.128.98.0/24,74.203.184.0/24,74.200.60.0/24,209.222.82.0/24
Domain_Whitelist = harrimanre.com,ventusnetworks.com,digi.com
Re: SPF and policyd
On Sunday, February 20, 2022 10:26:56 AM EST Alex wrote:
> Hi, I'm using the SPF policyd service recommended here some time ago.
> I hoped I could ask some questions about how it works since it doesn't
> appear to have any other direct support avenues available.
>
> I'm trying to understand the following log entry:
>
> Feb 20 10:01:59 armor policyd-spf[2466782]: prepend X-Comment: SPF
> skipped for whitelisted relay domain - client-ip=168.245.99.219;
> helo=o25.sg.marketing.agoda.global;
> envelope-from=bounces+8548506-62a0-05448=hotel.example.com@marketing.agoda.g
> lobal; receiver=
>
> None of the IPs or domains listed above are in my local whitelist, but
> the IP is listed in the SPF record for marketing.agoda.global. Is that
> what it is referring to? I tried tracing the code, but I'm not much of
> a python programmer.
>
> It appears to check the SPF record for the domain in the whitelist,
> not the sending domain. bypass_list_list is the whitelist entries in
> my config.
>
> for domain in bypass_list_list:
>res = spf.check2(ip, domain, domain,
> querytime=configData.get('Whitelist_Lookup_Time'))
>if domain_res[0] == 'Pass':
>...
>
> and if it results in "Pass", then it returns True if the domain in the
> whitelist entry, not the sending domain?
>
> Here's how I have it set up:
> policy-spf unix - n n - - spawn
> user=nobody argv=/usr/libexec/postfix/policyd-spf
>
> And the relevant info from my policyd-spf.conf:
> skip_addresses =
> 139.138.56.0/24,127.0.0.0/8,209.216.90.0/24,:::127.0.0.0/104,::1,52.128.
> 98.0/24,74.203.184.0/24,74.200.60.0/24,209.222.82.0/24 Domain_Whitelist =
> harrimanre.com,ventusnetworks.com,digi.com
That looks like it is working as documented. Here's the definition of
Domain_Whitelist:
Domain_Whitelist: List of domains whose sending IPs should be whitelisted from
SPF checks. Use this to list trusted forwarders by domain name. Client IP
addresses are tested against SPF records published by the listed domains. This
is useful for large forwarders with complex outbound infrastructures and SPF
records. This option is less scalable than the SPF IP Whitelist. An x-header
is prepended indicating the IP was whitelisted against SPF checks. This is a
trace header only. This option does nothing if the domain does not have an
SPF record. In this case use the SPF IP Whitelist described above or
Domain_Whitelist_PTR (below).
See man 5 policyd-spf.conf for additional information. If that's not what you
want to have happen, you should look at the other options that are mentioned.
https://git.launchpad.net/spf-engine/tree/policyd-spf.conf.5
Scott K
Re: canonical_maps vs. *_recipient_maps
Dnia 18.02.2022 o godz. 11:17:13 Wietse Venema pisze: Starting to wonder if reject_unverified_recipient should be given more publicity. I needed to reread http://www.postfix.org/ADDRESS_VERIFICATION_README.html but yes, looks like it needs exactly this publicity. Jaroslaw Rafa: Definitely should. I always thought of reject_unverified_recipient only in context of a front-end server relaying mail to the final server, which is a pretty rare case for me (I usually work with single-server setups). I did not think that it can be used in such context as rewriting by canonical maps. the same by me. Thanks for pointing out, Wietse. On 2/18/22 12:20, Wietse Venema wrote: Upon closer reading, address verification has limits some of which are intentional. Address verification will validate addresses that result from canonical mappings and of 1-to-1 virtual aliases. This should be enough for most cases. Address verification will not validate addresses that result from the expansion of 1-to-many virtual aliases. It will just report that the address before alias expansion is valid. It does not validate 1-to-many expansions because that would result in an explosive behavior, because the result would ambiguous if some addresses in the expansion result are valid and some not, and because it could be undesirable to reveal what 1-to-many aliases expand into. While mapping to multiple recipients could fail if none of them exists, this is more an error of admins/configuration and one should not expect postfix to do everything for them. (not that I didn't think of something like this for different case, but I'm not a programmer so it would take much time for me) Address verification will also not validate addresses that result from local aliasing/forwarding with alias_maps or ~/.forward files, because I was too lazy to write code that determines if these are 1-to-1 or 1-to-many, but also because it might reveal too much information. It will just report that the address before alias expansion or forwarding is valid. On 20.02.22 01:43, Demi Marie Obenour wrote: Is reject_unverified_recipient the correct approach for a standard Postfix/Dovecot setup? it should not be needed unless your postfix instance does not know whether final recipients exist. Imho it's always better to make it know but reject_unverified_recipient looks like good workaround. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. I'm not interested in your website anymore. If you need cookies, bake them yourself.
Re: virtual_mailbox_maps & virtual_alias_maps
On 20.02.22 18:49, Phil Biggs wrote: I have virtual_mailbox_maps in use with reject_unlisted_recipent and use virtual_alias_maps to translate a validated address into a single matching address for the corresponding dovecot user. virtual_alias_maps map any address (even non-local one) to one or more addresses: http://www.postfix.org/ADDRESS_REWRITING_README.html#virtual virtual_mailbox_maps map addresses in virtual domains into pathnames where mailboxes are located: http://www.postfix.org/virtual.8.html so, they have quite different usage. For example: /usr/local/etc/postfix/vmailbox validu...@example.com whatever /usr/local/etc/postfix/vuser validu...@example.com dovecotu...@example.com In my case, these two tables will always match on the LHS. Just wondering whether there any reason not to use the virtual_alias table for both purposes? It would make synchronisation with the dovecot users DB just a little easier. you don't need synchronization, and you apparently don't need virtual_alias_maps in this case. virtual_mailbox_maps = hash:/usr/local/etc/postfix/vuser virtual_alias_maps = hash:/usr/local/etc/postfix/vuser (Mail sent directly to dovecotu...@example.com should be rejected.) you must take care of this differently. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. "To Boot or not to Boot, that's the question." [WD1270 Caviar]
Re: virtual_mailbox_maps & virtual_alias_maps
Monday, February 21, 2022, 5:04:59 AM, Matus UHLAR - fantomas wrote: > On 20.02.22 18:49, Phil Biggs wrote: >>I have virtual_mailbox_maps in use with reject_unlisted_recipent and use >>virtual_alias_maps to translate a validated address into a single matching >>address for the corresponding dovecot user. > virtual_alias_maps map any address (even non-local one) to one or more > addresses: > http://www.postfix.org/ADDRESS_REWRITING_README.html#virtual > virtual_mailbox_maps map addresses in virtual domains into pathnames where > mailboxes are located: > http://www.postfix.org/virtual.8.html > so, they have quite different usage. >> For example: >> >>/usr/local/etc/postfix/vmailbox >>validu...@example.com whatever >> >>/usr/local/etc/postfix/vuser >>validu...@example.com dovecotu...@example.com >> >>In my case, these two tables will always match on the LHS. >> >>Just wondering whether there any reason not to use the virtual_alias table for >>both purposes? It would make synchronisation with the dovecot users DB just a >>little easier. > you don't need synchronization, and you apparently don't need > virtual_alias_maps in this case. >>virtual_mailbox_maps = hash:/usr/local/etc/postfix/vuser >>virtual_alias_maps = hash:/usr/local/etc/postfix/vuser >> >>(Mail sent directly to dovecotu...@example.com should be rejected.) > you must take care of this differently. Thanks for the reply, Matus. Perhaps I didn't explain this very well. I read the linked documents many times before doing what I have and the current configuration works as I expected: - emails sent to (external) validuser@ addresses are validated as present in virtual_mailbox_maps - validuser@ addresses are translated to (internal) dovecotuser@ via virtual_alias_maps - only dovecotuser@ addresses are accepted by dovecot - emails originally addressed to dovecotuser@ addresses are rejected Perhaps this is not the intended use but it certainly works. The question was about whether there might be a problem with using the same hash table for both virtual_mailbox_maps and virtual_alias_mapps. That would mean I only need to update the virtual_alias_maps and the dovecot 'users' DB, which must be in sync. -- Cheers, Phil
