On 2/4/25 4:15 AM, Wietse Venema via Postfix-users wrote:
Ellie via Postfix-users:
The submission configurations as distributed have
smtpd_recipient_restrictions=permit_sasl_authenticated,reject
which will reject mail without SASL login.
Wietse
Thank you so much for the clarifying
On 2/3/25 11:56 PM, Wietse Venema via Postfix-users wrote:
master.cf:
submission .. .. .. .. .. .. .. smtpd
-o { header_checks = pcre:{{/^Received:/ IGNORE}} }
...other -o options...
submissions .. .. .. .. .. .. .. smtpd
-o { header_checks = pcre:{{/^Receive
Ellie via Postfix-users:
> On 2/3/25 11:56 PM, Wietse Venema via Postfix-users wrote:
> > If this is for messages submitted on port 587 (submission) or 465
> > (smtps or submissions), then you can simply delete all Received:
> > message headers, because there shuold be only one.
> Thanks so much fo
On 2/4/25 2:25 AM, Viktor Dukhovni via Postfix-users wrote:
Though one might want to be prepared to encounter more friction for
outbound mail lacking all upstream Received headers. These tend to
be classed more "spammy".
This made me curious, and I've checked a bunch of incoming mail. Many
m
On 2/3/25 11:56 PM, Wietse Venema via Postfix-users wrote:
If this is for messages submitted on port 587 (submission) or 465
(smtps or submissions), then you can simply delete all Received:
message headers, because there shuold be only one.
Thanks so much for your helpful response! I wonder, does
On Mon, Feb 03, 2025 at 05:56:45PM -0500, Wietse Venema via Postfix-users wrote:
> There is no built-in featrue to delete IP addresses from headers.
But, given the expected header form, it is not difficult to craft a PCRE
table that does the job well.
> If this is for messages submitted on port
Ellie via Postfix-users:
> Dear postfix users group,
>
> Sorry if this is the wrong place to ask, or if this is a nonsensical
> question.
>
> But it seems to me that discarding the exact end-user device IP from
> e-mails sent via any authenticated path is going to be a common scenario
> in tod
Dear postfix users group,
Sorry if this is the wrong place to ask, or if this is a nonsensical
question.
But it seems to me that discarding the exact end-user device IP from
e-mails sent via any authenticated path is going to be a common scenario
in today's more privacy aware age.
Yet, it
On 4/02/25 09:53, Emmanuel Seyman via Postfix-users wrote:
* Josh Good via Postfix-users [31/01/2025 00:37] :
There were community-provided RPM packages of Postfix for Red Hat 6.2
(Classic), as noted in the original post for this thread, but none of
them seems to have survived on any publicly a
Bill Cole via Postfix-users:
> On 2025-02-03 at 13:07:38 UTC-0500 (Mon, 3 Feb 2025 13:07:38 -0500)
> Dan Mahoney via Postfix-users
> is rumored to have said:
>
> > When calling ?postfix reload?, should "postfix/postfix-script: refreshing
> > the Postfix mail system? be written to stderr?
>
> Ye
* Josh Good via Postfix-users [31/01/2025 00:37] :
>
> There were community-provided RPM packages of Postfix for Red Hat 6.2
> (Classic), as noted in the original post for this thread, but none of
> them seems to have survived on any publicly accessible repository today.
I had the pleasure of meet
On 2025-02-03 at 13:07:38 UTC-0500 (Mon, 3 Feb 2025 13:07:38 -0500)
Dan Mahoney via Postfix-users
is rumored to have said:
> When calling “postfix reload”, should "postfix/postfix-script: refreshing the
> Postfix mail system” be written to stderr?
Yes.
> It’s not an error, and it feels like th
Dan Mahoney via Postfix-users:
> All,
>
> This is the most minor problem, but I'll bring it up.
>
> We use Lets Encrypt for our certs (using the Dehydrated client),
> and call a 'postfix reload' as part of the hook script if a cert
> has been renewed.
>
> We also wrapper this with ?cronic' which
All,
This is the most minor problem, but I’ll bring it up.
We use Lets Encrypt for our certs (using the Dehydrated client), and call a
“postfix reload” as part of the hook script if a cert has been renewed.
We also wrapper this with ‘cronic’ which works not under the old cron principle
that “a
Hello,
thanks for the clarification.
Regards
Klaus.
- Nachricht von Wietse Venema via Postfix-users
-
Datum: Mon, 3 Feb 2025 12:02:59 -0500 (EST)
Von: Wietse Venema via Postfix-users
Antwort an: Wietse Venema
Betreff: [pfx] Re: smtpd_end_of_data_restrictions an
Klaus Tachtler via Postfix-users:
> Hello,
>
> just so I understand correctly, the recommendation would be to use
> smtpd_end_of_data_restrictions, despite the warning in the Dovecot log?
No. The recommendation is to use the software as intended by its
author, not at end-of-data.
Wietse
Hello,
just so I understand correctly, the recommendation would be to use
smtpd_end_of_data_restrictions, despite the warning in the Dovecot log?
Thank you
Klaus.
On 2/3/25 17:39, Wietse Venema via Postfix-users wrote:
Klaus Tachtler via Postfix-users:
Hello,
I have a question about smtpd
Klaus Tachtler via Postfix-users:
> Hello,
>
> I have a question about smtpd_end_of_data_restrictions. In the
> documentation under the following link
> https://www.postfix.org/SMTPD_ACCESS_README.html#lists there is an
> example which looks like this:
>
> # Enforce mail volume quota via
Hello,
I have a question about smtpd_end_of_data_restrictions. In the
documentation under the following link
https://www.postfix.org/SMTPD_ACCESS_README.html#lists there is an
example which looks like this:
# Enforce mail volume quota via policy service callouts.
smtpd_end_of_data_re
19 matches
Mail list logo
