On Wed, Feb 05, 2025 at 15:31:44 +0100, Ömer Güven via Postfix-users wrote:
> At least the big companies like GMail never complained about it, the
> Authenticated Received Chain (ARC) always passes without errors, even
> for forwarding. :-)
Yes, the message is still RFC 5322 compliant, as Viktor
At least the big companies like GMail never complained about it, the
Authenticated Received Chain (ARC) always passes without errors, even for
forwarding. :-)
> Am 05.02.2025 um 15:28 schrieb Geert Hendrickx via Postfix-users
> :
>
> On Wed, Feb 05, 2025 at 14:58:48 +0100, Ömer Güven via Post
On Wed, Feb 05, 2025 at 14:58:48 +0100, Ömer Güven via Postfix-users wrote:
> My solution does completely remove the Received header, so that the
> next-hop adds an appropriate one, usually pointing to the sending MX‘
> ip address.
Which is also not RFC 5321 compliant, just not visibly so :)
>
Geert Hendrickx via Postfix-users:
> On Tue, Feb 04, 2025 at 17:09:52 -0500, Wietse Venema via Postfix-users wrote:
> > This reduces the Received: header from:
> >
> > Received: from
> > by servername (Postfix) with id yyy; server-date-stamp
> >
> > to:
> >
> > Received: by
On Wed, Feb 05, 2025 at 02:01:27PM +0100, Geert Hendrickx via Postfix-users
wrote:
> It seems that such reduced Received header would not be RFC5321 compliant,
> as the "from " clause is mandatory according to section 4.4.
It is still a valid Received header, just like the ones added by
submissi
My solution does completely remove the Received header, so that the next-hop
adds an appropriate one, usually pointing to the sending MX‘ ip address.
The MX doesn’t have to forward any sensitive information about the MUA to the
receiving MTA.
Ömer
> Am 05.02.2025 um 14:02 schrieb Geert Hendri
On Tue, Feb 04, 2025 at 17:09:52 -0500, Wietse Venema via Postfix-users wrote:
> This reduces the Received: header from:
>
> Received: from
> by servername (Postfix) with id yyy; server-date-stamp
>
> to:
>
> Received: by servername (Postfix) with id yyy; server-date
Oops, sorry. My initial mail was sent 6 hours ago, but I forgot to Reply-All.
Meanwhile, there is already another solution provided.
Ömer
> Am 05.02.2025 um 08:19 schrieb Ömer Güven via Postfix-users
> :
>
>
> Hi!
>
> I didn‘t read the whole thread but I understand that you want to strip
Hi!
I didn‘t read the whole thread but I understand that you want to strip privacy
relevant user data from MUA submissions.
In master.cf, add twice, one for smtps (port 465) and one for submission (port
587):
-o cleanup_service_name=submission-header-cleanup
Then add this line to the same
On Tue, Feb 04, 2025 at 05:09:52PM -0500, Wietse Venema via Postfix-users wrote:
> I will implement Ellie's request, and move the Postfix 3.10 code
> freeze up by a few days.
>
> smtpd_hide_session_info (default: no)
>
> Hide SMTP session info from the Received: message header. Do not
> record th
Good morning,
out of curiosity, does it possibly -if implemented- break ARC signature
creation of e.g. rspamd, which seems to use auth-info?
ARC-Authentication-Results: i=1;
ORIGINATING;
auth=pass smtp.auth=u...@doma.in smtp.mailfrom=u...@doma.in
Or is this transferred via MILT
On Tue, Feb 04, 2025 at 08:17:08PM -0500, postfix--- via Postfix-users wrote:
> > If the intent is to only censor submission, This is not correct, it will
> > drop all "Received" headers from any mail that is not delivered locally,
> > so entirely unsuitable for relaying non-submission mail, risks
And Smtp header checks get applied to (smtp) mail received by submission on
its way out to the world.
NO. "smtp_header_checks" are applied on output to all mail that leaves
the system, regardless of how it arrived, whether inbound from a remote
source, an SMTP submission, or generated locally.
On Tue, Feb 04, 2025 at 06:29:47PM -0500, postfix--- via Postfix-users wrote:
> I might have misunderstood the point of this as im jumping in late, but
> there is both `header_checks` and `smtp_header_checks`.
> Normal header checks get applied to (smtpd) mail being received on port 25
> on it's w
-o { smtp_header_checks = pcre:{{/^Received:/ IGNORE}} }
I don't know if that is valid syntax. It might need to be done in main
instead of master. Not every postfix setting works in master.
Hopeful someone more knowledgeable can step in.
___
Postfi
On 2/5/25 12:29 AM, postfix--- via Postfix-users wrote:
I might have misunderstood the point of this as im jumping in late, but
there is both `header_checks` and `smtp_header_checks`.
That seems very promising, I tried to put it into practice right now:
smtp inet n - n - - smtpd
-o smtpd_tls
smtpd_hide_session_info (default: no)
Hide SMTP session info from the Received: message header. Do not
record the SMTP client name or IP address, SASL login name, or TLS
session details. This reduces the Received: header from:
Received: from
by servername (Postfix) with id
ellie via Postfix-users:
> I sent a test mail to a throwaway account now, and found the according
> log entry! The one you wanted was gone since I happened to have reboot
> with wiped logs since then. I hope it shows something helpful :-o sorry
> again for the effort.
OK, so I have forgotten ho
On 2/4/25 19:48, Wietse Venema via Postfix-users wrote:
What did Postfox log at 18:06:46 - postfix/submission/smtpd or postfix/smtpd?
Wietse
I sent a test mail to a throwaway account now, and found the according
log entry! The one you wanted was gone since I happened to have reboot
Ellie via Postfix-users:
> Yet "Received" still seems present in full, you can see it with this
> e-mail I'm typing in this moment.
Received: from [10.42.0.75]
(dynamic-176-003-178-138.176.3.pool.telefonica.de
[176.3.178.138])
by mail.ekdawn.com (Postfix) with ESMTPSA
On 2/4/25 7:07 PM, Ellie via Postfix-users wrote:
Sorry for me perhaps bugging this again! I pondered how I could possibly
be using the wrong file, but I can't think of anything.
To rule out that pcre is the issue, I installed all versions of pcre and
pcre2 both 16 and 32 that Alpine Linux off
On 2/4/25 7:00 PM, Wietse Venema via Postfix-users wrote:
You forgot to "postfix reload", or you edited the wrong master.cf
file.
What is the output from:
postconf -Mf submission/inet
It should show the new header_checks setting.
These master.cf sttings override main.cf so no need to del
Ellie via Postfix-users:
> On 2/4/25 4:50 PM, Wietse Venema via Postfix-users wrote:
> > Yes you did. You forgot to start line 16 with a space or tab.
> >
> > Wietse
> Oops, how silly, sorry! Okay, I think I got it:
>
> smtp inet n - n - - smtpd
>-o smtpd_tls_security_level=encrypt
>-
Viktor Dukhovni via Postfix-users:
> 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 w
On 2/4/25 4:50 PM, Wietse Venema via Postfix-users wrote:
Yes you did. You forgot to start line 16 with a space or tab.
Wietse
Oops, how silly, sorry! Okay, I think I got it:
smtp inet n - n - - smtpd
-o smtpd_tls_security_level=encrypt
-o { header_checks=regexp:/etc/postfix/header
Ellie via Postfix-users:
> mail-1 | /usr/sbin/postconf: fatal: file /etc/postfix/master.cf: line
> 16: bad field count
>
> (Sorry if I did something super obvious wrong!)
Yes you did. You forgot to start line 16 with a space or tab.
Wietse
__
On 2025-02-03 at 21:55:14 UTC-0500 (Tue, 4 Feb 2025 03:55:14 +0100)
Ellie via Postfix-users
is rumored to have said:
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 a
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
34 matches
Mail list logo
