[pfx] Re: reject_unverified_sender: parallelism seems sub-optimal
Wietse Venema via Postfix-users wrote in
<4yzbyp1lr9zj...@spike.porcupine.org>:
|Steffen Nurpmeso via Postfix-users:
...
|> i again stumbled over the fact that postfix receives many
|> successive mails from these servers, then creates / refreshes the
|> verify_sender DB, but seems to have "no state machine" regarding
|> sender verification, but simply "brute force verifies", for
|> example here:
|>
|> Jan 14 15:16:16 postfix/smtp[892]: 4013616065: to= 86bdd37fc8981.rf5167a6a-eb83-11e9-92f5-7ab8f5b1d025@9fans.bounce.topicb\
|> ox.com>, relay=mx1.topicbox.com[103.168.172.233]:25, delay=1.6, \
|> delays=0.02/0.17/1.3/0.14, dsn=2.1.5, status=deliverable (250 2.1.5 Ok)
|> ..
|> Jan 14 15:16:16 postfix/smtp[893]: 8D64D16067: to= 1ed0ef138d2f7.rf5167a6a-eb83-11e9-92f5-7ab8f5b1d025@9fans.bounce.topicb\
|> ox.com>, relay=mx1.topicbox.com[103.168.172.232]:25, delay=1.6, \
|> delays=0.01/0.23/1.2/0.19, dsn=2.1.5, status=deliverable (250 2.1.5 Ok)
|> ...
|> Jan 14 15:16:16 postfix/smtp[891]: 586AF16066: to= 103059818efab.rf5167a6a-eb83-11e9-92f5-7ab8f5b1d025@9fans.bounce.topicb\
|> ox.com>, relay=mx1.topicbox.com[103.168.172.233]:25, delay=1.7, \
|> delays=0.01/0.1/1.4/0.13, dsn=2.1.5, status=deliverable (250 2.1.5 Ok)
|>
|> today two in parallel, but it can be more even, it seems unbound
|> (by itself).
|>
|> Could anything be done about that, aka synchronization be
|> enforced? I also seem to remember being fooled by nonsense mails
|
|Technically, those are THREE DIFFERENT email addresses:
Hm. Logical. pfffhh...
|bounce.mMf69fb7a2ec786bdd37fc8981.rf5167a6a-eb83-11e9-92f5-7ab8f5b1d025\
|@...
|bounce.mM1d0608a97b91ed0ef138d2f7.rf5167a6a-eb83-11e9-92f5-7ab8f5b1d025\
|@...
|bounce.mM0295fcc211a103059818efab.rf5167a6a-eb83-11e9-92f5-7ab8f5b1d025\
|@9...
|
|What kind of logic do you have in mind to cache these different
|sender addresses under the same address verification cache lookup
|key? You could play games with smtpd_command_maps, but...
verp delimiter is none there, that much is plain.
|What is the point of using reject_unverified_sender for this email?
|
|On my own site, I use it only against clients without proper FCRNS.
|(check_client_access inline:{unknown=reject_unverified_sender})
Yes, i now
allow .messagingengine.com
in addition to the
allow .topicbox.com
i already had..
Maybe in this modern world one should create a script and to
a full MX/A/ chain lookup of all mailing-lists one is
subscribed to, and auto-whitelist all of those.
Sorry for the noise.
--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
|
|In Fall and Winter, feel "The Dropbear Bard"s pint(er).
|
|The banded bear
|without a care,
|Banged on himself for e'er and e'er
|
|Farewell, dear collar bear
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Is that correct behaviour?
On Fri, Jan 17, 2025 at 08:57:02AM +0100, Tobi via Postfix-users wrote: > > That would be unexpected. I'm implementing support for REQUIRETLS > > (RFC 8689) and that code is supposed to try multiple MXes before it > > gives up. > > > > Have you perhaps configured smtp_mx_session_limit=1 ? > > > > postconf smtp_mx_session_limit > postconf smtp_mx_session_limit > smtp_mx_session_limit = 2 How many *IP addresses* (IPv4 and IPv6) does the primary MX have? If it is more than 1, the behaviour is as expected. Enforcing dane-only for a domain that does not publish TLSA RRs for all MX hosts imposes a monitoring burden, and willingness to use work-arounds, such as filtering the list of MX hosts you're willing to accept for the domain perhaps via "smtp_dns_reply_filter". The real solution is to coördinate with the domain owner to either enable DANE on all MX hosts, or set up non-DANE secure channel via some suitable set of trust anchors, ... -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] [mailop] FYI: nixspam RBL has shutdown
[ Repost from "mailop" list ] Just FYI for those with the nixspam RBL configured in their systems (For example it's enabled in rspamd by default) It's just shutdown - https://www.nixspam.net/?old_domain=true Sad to see as it was always quite reliable as a signal of spamminess IMHO. Make sure to remove it in case it starts returning false positives in the future! -- Viktor. 🇺🇦 Слава Україні! ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: reject_unverified_sender: parallelism seems sub-optimal
Steffen Nurpmeso via Postfix-users:
> Hello.
>
> Full picture: i am still at the 9fans mailing-list, which over
> time has been migrated to topicbox.com, and this is handled via
> messagingengine.com (it is saddening to do configuration via
> policy server as the two domains are distinct, sigh).
>
> Well, there started a lot of noise on these lists recently, for
> the first time since the new setup is active i think, and today
> i again stumbled over the fact that postfix receives many
> successive mails from these servers, then creates / refreshes the
> verify_sender DB, but seems to have "no state machine" regarding
> sender verification, but simply "brute force verifies", for
> example here:
>
> Jan 14 15:16:16 postfix/smtp[892]: 4013616065:
> to=,
> relay=mx1.topicbox.com[103.168.172.233]:25, delay=1.6,
> delays=0.02/0.17/1.3/0.14, dsn=2.1.5, status=deliverable (250 2.1.5 Ok)
> ..
> Jan 14 15:16:16 postfix/smtp[893]: 8D64D16067:
> to=,
> relay=mx1.topicbox.com[103.168.172.232]:25, delay=1.6,
> delays=0.01/0.23/1.2/0.19, dsn=2.1.5, status=deliverable (250 2.1.5 Ok)
> ...
> Jan 14 15:16:16 postfix/smtp[891]: 586AF16066:
> to=,
> relay=mx1.topicbox.com[103.168.172.233]:25, delay=1.7,
> delays=0.01/0.1/1.4/0.13, dsn=2.1.5, status=deliverable (250 2.1.5 Ok)
>
> today two in parallel, but it can be more even, it seems unbound
> (by itself).
>
> Could anything be done about that, aka synchronization be
> enforced? I also seem to remember being fooled by nonsense mails
Technically, those are THREE DIFFERENT email addresses:
bounce.mMf69fb7a2ec786bdd37fc8981.rf5167a6a-eb83-11e9-92f5-7ab8f5b1d025@...
bounce.mM1d0608a97b91ed0ef138d2f7.rf5167a6a-eb83-11e9-92f5-7ab8f5b1d025@...
bounce.mM0295fcc211a103059818efab.rf5167a6a-eb83-11e9-92f5-7ab8f5b1d025@9...
What kind of logic do you have in mind to cache these different
sender addresses under the same address verification cache lookup
key? You could play games with smtpd_command_maps, but...
What is the point of using reject_unverified_sender for this email?
On my own site, I use it only against clients without proper FCRNS.
(check_client_access inline:{unknown=reject_unverified_sender})
Wietse
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] reject_unverified_sender: parallelism seems sub-optimal
Hello.
Full picture: i am still at the 9fans mailing-list, which over
time has been migrated to topicbox.com, and this is handled via
messagingengine.com (it is saddening to do configuration via
policy server as the two domains are distinct, sigh).
Well, there started a lot of noise on these lists recently, for
the first time since the new setup is active i think, and today
i again stumbled over the fact that postfix receives many
successive mails from these servers, then creates / refreshes the
verify_sender DB, but seems to have "no state machine" regarding
sender verification, but simply "brute force verifies", for
example here:
Jan 14 15:16:16 postfix/smtp[892]: 4013616065:
to=,
relay=mx1.topicbox.com[103.168.172.233]:25, delay=1.6,
delays=0.02/0.17/1.3/0.14, dsn=2.1.5, status=deliverable (250 2.1.5 Ok)
..
Jan 14 15:16:16 postfix/smtp[893]: 8D64D16067:
to=,
relay=mx1.topicbox.com[103.168.172.232]:25, delay=1.6,
delays=0.01/0.23/1.2/0.19, dsn=2.1.5, status=deliverable (250 2.1.5 Ok)
...
Jan 14 15:16:16 postfix/smtp[891]: 586AF16066:
to=,
relay=mx1.topicbox.com[103.168.172.233]:25, delay=1.7,
delays=0.01/0.1/1.4/0.13, dsn=2.1.5, status=deliverable (250 2.1.5 Ok)
today two in parallel, but it can be more even, it seems unbound
(by itself).
Could anything be done about that, aka synchronization be
enforced? I also seem to remember being fooled by nonsense mails
which then cause sender verification to kick in to unrelated
things, but i have forgotten about the details, actually.
I am also totally rusty regarding DNS, off-topic.., but if i do
"dig topicbox.com" i get "103.168.172.5" for another 178 seconds,
but if i do "dig -x 103.168.172.5" i get NXDOMAIN by
messagingengine.com, which is what one gets when asking for MX of
topicbox.com. It seems no good.. whatever. Maybe someone reads
that..
Relevant config is
# MAIL FROM Checks
smtpd_sender_restrictions =
# permit_inet_interfaces, OR
permit_mynetworks,
#RELAY reject_authenticated_sender_login_mismatch,
permit_tls_clientcerts,
#[RELAY] permit_sasl_authenticated,
reject_non_fqdn_sender,
check_sender_access inline:{$mydomain=reject},
# Total no-goes database, eg: qq.com reject
#check_sender_access lmdb:$meta_directory/sender_restrict,
reject_unknown_sender_domain,
reject_unknown_reverse_client_hostname,
#GRAY: with --focus-sender only! And --msg-allow=permit
check_policy_service unix:private/postgray,
reject_unverified_sender,
permit
--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
|
|In Fall and Winter, feel "The Dropbear Bard"s pint(er).
|
|The banded bear
|without a care,
|Banged on himself for e'er and e'er
|
|Farewell, dear collar bear
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] TLSRPT broken confirmed, starting with 3.10-snapshot 20250105
Hello, sorry to have a similar, but different thread subject. I already deleted the others, so couldn't backup on those mails and just thought, hey, I have a look at my system. But I can confirm the non-working condition of the TLSRPT part of postfix, starting with snapshot 3.10-20250105, for me on 06.01.2025 06:05h, just after updating from the previous snapshot. I just re-compiled it, no errors. JFYI. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Is that correct behaviour?
Wietse: > Have you perhaps configured smtp_mx_session_limit=1 ? > > postconf smtp_mx_session_limit > postconf -P '*/*/smtp_mx_session_limit' Tobi: > postconf smtp_mx_session_limit > smtp_mx_session_limit = 2 > postconf -P '*/*/smtp_mx_session_limit' > postconf: warning: unmatched request: "*/*/smtp_mx_session_limit" Wietse: > (same question for smtp_mx_address_limit=1). Tobi: > postconf smtp_mx_address_limit > smtp_mx_address_limit = 5 and postconf -P '*/*/smtp_mx_address_limit'? Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: TLSRPT issue
Hello all, I can confirm it works again for me now. Thank you Wietse! ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: TLSRPT issue
Am 17.01.25 um 15:00 schrieb Florian Piekert via Postfix-users: I can confirm it works again for me now. same here, thanks Wietse! Andreas ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: TLSRPT issue
postfix-3.10-20250116 has been uploaded to ftp.porcupine.org. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
