On 2022-03-19 17:49, Matus UHLAR - fantomas wrote:
this should be fixable by using proxymap, better than disabling chroot
http://www.postfix.org/proxymap.8.html
On 20.03.22 17:29, Jesper Dybdal wrote:
Thanks. As far as I can see, I need to add
proxy:regexp:/etc/postfix/regexp_milter_header_checks
to proxy_read_maps. But proxy_read_maps has a long default value - is
there a not-too-ugly way to add my milter header checks to the value
without losing the default value contents?
the funny part is that I have just encountered this problem, completely
forgetting I solved it for you a month ago ;-)
wietse already answered, so far I only added comment to the main.cf:
milter_header_checks = proxy:regexp:/etc/postfix/milter_header_checks.regexp
# defaults + $milter_header_checks
proxy_read_maps=$local_recipient_maps $mydestination $virtual_alias_maps
$virtual_alias_domains $virtual_mailbox_maps $virtual_mailbox_domains
$relay_recipient_maps $relay_domains $canonical_maps $sender_canonical_maps
$recipient_canonical_maps $relocated_maps $transport_maps $mynetworks
$smtpd_sender_login_maps $sender_bcc_maps $recipient_bcc_maps
$smtp_generic_maps $lmtp_generic_maps $alias_maps $smtpd_client_restrictions
$smtpd_helo_restrictions $smtpd_sender_restrictions $smtpd_relay_restrictions
$smtpd_recipient_restrictions
$address_verify_sender_dependent_default_transport_maps
$address_verify_sender_dependent_relayhost_maps $address_verify_transport_maps
$fallback_transport_maps $lmtp_discard_lhlo_keyword_address_maps
$lmtp_pix_workaround_maps $lmtp_sasl_password_maps $lmtp_tls_policy_maps
$mailbox_command_maps $mailbox_transport_maps
$postscreen_discard_ehlo_keyword_address_maps $rbl_reply_maps
$sender_dependent_default_transport_maps $sender_dependent_relayhost_maps
$smtp_discard_ehlo_keyword_address_maps $smtp_pix_workaround_maps
$smtp_sasl_password_maps $smtp_tls_policy_maps
$smtpd_discard_ehlo_keyword_address_maps $smtpd_milter_maps $virtual_gid_maps
$virtual_uid_maps $milter_header_checks
(OT: Having looked at log files while implementing DMARC check, I am
surprised to see that it seems to be not very unusual for companies to
have p=reject in their DMARC policy but still send mail that does not
pass DMARC - in some cases even with neither SPF nor DKIM. I'm
beginning to fear that it will be a while before DMARC can be really
useful...)
since I did some statistic for our customer curious about this problem,
there is one huge problem with this, and that is (of course) Microsoft.
looks like neither exchange servers nor their 365 services sign
(non-)delivery messages, even when they contain their domains in From:, so
if you use either of those, you can't afford any other policy than none.
OTOH, rejecting DMARC failures with policy reject should be not a problem,
since there's just a few of them.
--
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.
2B|!2B, that's a question!
