[pfx] Re: Is it possible/easy to block incoming for the real account name but accept the alias/canonical?

> On 26 Jan 2025, at 14:33, Wietse Venema via Postfix-users > wrote: > > Gerben Wierda via Postfix-users: >> >>> On 23 Jan 2025, at 17:55, Wietse Venema via Postfix-users >>> wrote: >>> >>> Gerben Wierda via Postfix-users:

[pfx] Re: Is it possible/easy to block incoming for the real account name but accept the alias/canonical?

> On 23 Jan 2025, at 17:55, Wietse Venema via Postfix-users > wrote: > > Gerben Wierda via Postfix-users: >> I was wondering, suppose I have a user like this: >> >> f...@bar.com is the account name >> foo.lastn...@bar.com is the incoming alias and the out

[pfx] Re: Is it possible/easy to block incoming for the real account name but accept the alias/canonical?

On 23 Jan 2025, at 17:55, Wietse Venema via Postfix-users wrote: > > Gerben Wierda via Postfix-users: >> I was wondering, suppose I have a user like this: >> >> f...@bar.com is the account name >> foo.lastn...@bar.com is the incoming alias and the outgoing

[pfx] Is it possible/easy to block incoming for the real account name but accept the alias/canonical?

I was wondering, suppose I have a user like this: f...@bar.com is the account name foo.lastn...@bar.com is the incoming alias and the outgoing canonical Could I force incoming mail to accept the alias form, but not accept the account form? I.e. f...@bar.com as address is blocked, but foo.lastn..

[pfx] Re: HAproxy 4.3 thinks one of my postfixes (3.9) is down on SMTP, but it sees another (3.8.6) as up on SMTP (SMTPD/postscreen are OK on both sides)

> On 31 May 2024, at 16:13, Wietse Venema via Postfix-users > wrote: > > Gerben Wierda via Postfix-users: >>> On 31 May 2024, at 14:53, Wietse Venema wrote: >>> >>> Gerben Wierda via Postfix-users: >>>> >>>>> On

[pfx] Re: HAproxy 4.3 thinks one of my postfixes (3.9) is down on SMTP, but it sees another (3.8.6) as up on SMTP (SMTPD/postscreen are OK on both sides)

> On 31 May 2024, at 14:53, Wietse Venema wrote: > > Gerben Wierda via Postfix-users: >> >>> On 31 May 2024, at 13:20, pat...@patpro.net wrote: >>> >>> Hello, >>> >>> Any sign of postfix 3.9 blacklisting HAproxy because of SMTP >

[pfx] whitelisting and greylisting

I have a whitelist file rna_rbl_whitelist_clients that contains: # Part of smtpd_recipient_restrictions (greylisting is managed per recipient) # These are the CLIENTS that are allowed to bypass greylisting /\.facebook\.com$/ OK /\.facebookmail\.com$/ OK and th

[pfx] Re: HAproxy 4.3 thinks one of my postfixes (3.9) is down on SMTP, but it sees another (3.8.6) as up on SMTP (SMTPD/postscreen are OK on both sides)

is sent before 220 is received? G > > May 31, 2024 1:06 PM, "Gerben Wierda via Postfix-users" > <mailto:postfix-users@postfix.org?to=%22gerben%20wierda%20via%20postfix-users%22%20%3cpostfix-us...@postfix.org%3E>> > wrote: > Hmm, I just noticed (all outgoing s

[pfx] HAproxy 4.3 thinks one of my postfixes (3.9) is down on SMTP, but it sees another (3.8.6) as up on SMTP (SMTPD/postscreen are OK on both sides)

Hmm, I just noticed (all outgoing smtp was going to a backup server that works) that one of my postfix instances cannot send mail (smtp doesn't work, postscreen and smtpd work fine). # submission (587) submission inet n - n - - smtpd -o smtpd_tls_security_level=en

[pfx] Re: A functional lightweight reverse alias?

> On 3 Mar 2024, at 19:24, Matus UHLAR - fantomas via Postfix-users > wrote: > > The question was if there is other solution for this. Indeed. If I use an alias in /etc/aliases, mail from X to that alias gets delivered to my original mailbox. If I reply, it gets sent from that original mail

[pfx] A functional lightweight reverse alias?

Aliases are nice, to receive mail. But when you reply, the address behind the alias is exposed. To prevent that I need to create full mailboxes, which requires a lot of administration in dovecot, postfix. Suppose - I am m...@mydomain.tld - At evilcompany.com they know be by my alias meatevilco

[pfx] CVE-2023-51764

Is smtpd_data_restrictions = reject_unauth_pipelining, permit_mynetworks, permit_sasl_authenticated, reject_multi_recipient_bounce enough to stop this small(?) risk (before I manage to upgrade)? Gerben Wierda (LinkedIn , M