[pfx] IP discard for authenticated e-mails
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 seems to be somewhat convoluted to do: https://askubuntu.com/a/78168 (My apologies if this is easy to all you experts, but I feel like to most postfix newcomers this is going to look somewhat difficult.) Is there any easier approach for doing this? Or was there ever a consideration for doing a simple yes/no option as a new feature for postfix, which omits the sender IP address from authenticated(!) incoming mail? I feel like there might be a wider demand for that. Regards, ell1e ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: IP discard for authenticated e-mails
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 response! Sorry for the confused questions, I hope this is helpful for somebody in the future finding it via search engines. Regards, ell1e ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: IP discard for authenticated e-mails
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:{{/^Received:/ IGNORE}} }
...other -o options...
This is much simpler than some of the on-line discussions.
I tested this out now, interestingly I get this issue:
mail-1 | /usr/sbin/postconf: fatal: file /etc/postfix/master.cf: line
16: bad field count
(Sorry if I did something super obvious wrong!)
Is my postfix version perhaps too old? I seem to be running 3.9.1 at the
moment, as packaged by Alpine Linux.
Regards,
ell1e
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: IP discard for authenticated e-mails
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 postfix reject unauthenticated mail from port 587 and 465, in the common config where open relay access is disabled? From reading my own master.cf I feel like it doesn't. Wouldn't it then strip from some external incoming mail as well? That would seem a little strange. Regards, ell1e ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: IP discard for authenticated e-mails
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 mails seem to replace the Received: headers that I assume previously listed individual clients, by listing some internal submission proxy instead. (Whether that proxy even exists, or is made up, or who knows.) That seems like a workaround for that issue. I'm still wondering if a postfix config option for this use case would help a lot of people. Regards, ell1e ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: IP discard for authenticated e-mails
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_checks_incoming }
submission inet n - n - - smtpd
-o syslog_name=postfix/submission
-o smtpd_tls_security_level=encrypt
-o smtpd_tls_auth_only=yes
-o local_header_rewrite_clients=static:all
-o { header_checks = pcre:{{/^Received:/ IGNORE}} }
-o {
smtpd_recipient_restrictions=reject_unknown_sender_domain,reject_invalid_helo_hostname,reject_unknown_helo_hostname,permit_sasl_authenticated,permit_mynetworks,reject
}
-o smtpd_reject_unlisted_recipient=no
-o smtpd_client_restrictions=
-o smtpd_helo_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_relay_restrictions=
-o milter_macro_daemon_name=ORIGINATING
I attached the master.cf file. Additionally, I nuked any
"header_checks=" from main.cf to avoid interference.
Sadly, "Received" headers seem to remain fully there. :-o
Would perhaps OpenDKIM or policyd-spf add "Received" back?
milter_default_action = accept
milter_protocol = 2
smtpd_milters = inet:localhost:8891
non_smtpd_milters = inet:localhost:8891
smtpd_recipient_restrictions=reject_unknown_sender_domain,reject_invalid_helo_hostname,reject_unknown_helo_hostname,permit_mynetworks,reject_unknown_client_hostname,check_policy_service
unix:private/policyd-spf, permit_mynetworks
(from main.cf)
I am very sorry for taking up anyone's time.
Regards,
ell1e#
# Postfix master process configuration file. For details on the format
# of the file, see the master(5) manual page (command: "man 5 master" or
# on-line: http://www.postfix.org/master.5.html).
#
# Do not forget to execute "postfix reload" after editing this file.
#
# ==
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (no)(never) (100)
# ==
smtp inet n - n - - smtpd
-o smtpd_tls_security_level=encrypt
-o { header_checks=regexp:/etc/postfix/header_checks_incoming }
submission inet n - n - - smtpd
-o syslog_name=postfix/submission
-o smtpd_tls_security_level=encrypt
-o smtpd_tls_auth_only=yes
-o local_header_rewrite_clients=static:all
-o { header_checks = pcre:{{/^Received:/ IGNORE}} }
-o {
smtpd_recipient_restrictions=reject_unknown_sender_domain,reject_invalid_helo_hostname,reject_unknown_helo_hostname,permit_sasl_authenticated,permit_mynetworks,reject
}
-o smtpd_reject_unlisted_recipient=no
-o smtpd_client_restrictions=
-o smtpd_helo_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_relay_restrictions=
-o milter_macro_daemon_name=ORIGINATING
#smtp inet n - n - 1 postscreen
#smtpd pass - - n - - smtpd
#dnsblog unix - - n - 0 dnsblog
#tlsproxy unix - - n - 0 tlsproxy
# Choose one: enable submission for loopback clients only, or for any client.
#127.0.0.1:submission inet n - n - - smtpd
#submission inet n - n - - smtpd
# -o syslog_name=postfix/submission
# -o smtpd_tls_security_level=encrypt
# -o smtpd_sasl_auth_enable=yes
# -o smtpd_tls_auth_only=yes
# -o local_header_rewrite_clients=static:all
# -o smtpd_reject_unlisted_recipient=no
# Instead of specifying complex smtpd__restrictions here,
# specify "smtpd__restrictions=$mua__restrictions"
# here, and specify mua__restrictions in main.cf (where
# "" is "client", "helo", "sender", "relay", or "recipient").
# -o smtpd_client_restrictions=
# -o smtpd_helo_restrictions=
# -o smtpd_sender_restrictions=
# -o smtpd_relay_restrictions=
# -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
# -o milter_macro_daemon_name=ORIGINATING
# Choose one: enable submissions for loopback clients only, or for any client.
#127.0.0.1:submissions inet n - n - - smtpd
#submissions inet n - n - - smtpd
# -o syslog_name=postfix/submissions
# -o smtpd_tls_wrappermode=yes
# -o smtpd_sasl_auth_enable=yes
# -o local_header_rewrite_clients=static:all
# -o smtpd_reject_unlisted_recipient=no
# Instead of specifying complex smtpd__restrictions here,
# specify "smtpd__restrictions=$mua__restrictions"
# here, and specify mua__restrictions in main.cf (where
# "" is "client", "helo", "sender", "relay", or "recipient").
# -o smtpd_client_restrictions=
# -o smtpd_helo_restrictions=
# -o smtpd_sender_restrictions=
# -o smtpd_relay_restrictions=
# -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
# -o milter_macro_daemon_name=ORIGINATING
#628 inet n -
[pfx] Re: IP discard for authenticated e-mails
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 offers and I restarted. Sadly that doesn't seem to have been the cause either. Regards, ell1e ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: IP discard for authenticated e-mails
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 delete header_checks
there.
Wietse
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.
I did a reload, and it seems to be listed by postconf:
# postconf -Mf submission/inet
submission inet n - n - - smtpd
-o syslog_name=postfix/submission
-o smtpd_tls_security_level=encrypt
-o smtpd_tls_auth_only=yes
-o local_header_rewrite_clients=static:all
-o {header_checks=pcre:{{/^Received:/ IGNORE}}}
-o
smtpd_recipient_restrictions=reject_unknown_sender_domain,reject_invalid_helo_hostname,reject_unknown_helo_hostname,permit_sasl_authenticated,permit_mynetworks,reject
-o smtpd_reject_unlisted_recipient=no
-o smtpd_client_restrictions=
-o smtpd_helo_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_relay_restrictions=
-o milter_macro_daemon_name=ORIGINATING
# postfix reload
/usr/sbin/postconf: warning: /etc/postfix/main.cf: unused parameter:
policy_time_limit=3600
postfix/postfix-script: refreshing the Postfix mail system
#
Yet "Received" still seems present in full, you can see it with this
e-mail I'm typing in this moment.
Regards,
ell1e
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: IP discard for authenticated e-mails
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 with wiped logs since then. I hope it shows something helpful :-o sorry again for the effort. Regards, ell1email-1 | [/var/log/mail.log] 2025-02-04 20:15:25 info postfix/submission/smtpd[1280]: connect from gw9.ff3l.net[144.76.31.247] mail-1 | [/var/log/mail.log] 2025-02-04 20:15:26 info postfix/submission/smtpd[1280]: B43D01834A7: client=gw9.ff3l.net[144.76.31.247], sasl_method=PLAIN, sasl_username=e...@mail.ekdawn.com mail-1 | [/var/log/mail.log] 2025-02-04 20:15:26 info postfix/cleanup[1260]: B43D01834A7: message-id= mail-1 | [/var/log/mail.log] 2025-02-04 20:15:26 info opendkim[478]: B43D01834A7: DKIM-Signature field added (s=dkim1, d=horse64.org) mail-1 | [/var/log/mail.log] 2025-02-04 20:15:26 info postfix/qmgr[598]: B43D01834A7: from=, size=1212, nrcpt=1 (queue active) mail-1 | [/var/log/mail.log] 2025-02-04 20:15:32 info postfix/submission/smtpd[1280]: disconnect from gw9.ff3l.net[144.76.31.247] ehlo=2 starttls=1 auth=1 mail=1 rcpt=1 data=1 quit=1 commands=8 mail-1 | [/var/log/mail.log] 2025-02-04 20:15:34 info postfix/smtp[1270]: B43D01834A7: to=, relay=mail.protonmail.ch[185.70.42.128]:25, delay=7.8, delays=0.36/0/5.9/1.6, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 4YnZQK5gSPz9vNwd) mail-1 | [/var/log/mail.log] 2025-02-04 20:15:34 info postfix/qmgr[598]: B43D01834A7: removed Return-Path: X-Original-To: mylittletestm...@proton.me Delivered-To: mylittletestm...@proton.me Authentication-Results: mail.protonmail.ch; dkim=pass (Good 4096 bit rsa-sha256 signature) header.d=horse64.org header.a=rsa-sha256 Authentication-Results: mail.protonmail.ch; dmarc=none (p=none dis=none) header.from=horse64.org Authentication-Results: mail.protonmail.ch; spf=pass smtp.mailfrom=horse64.org Authentication-Results: mail.protonmail.ch; arc=none smtp.remote-ip=159.69.120.39 Authentication-Results: mail.protonmail.ch; dkim=pass (4096-bit key) header.d=horse64.org header.i=@horse64.org header.b="1lDE0gJJ" Received: from mail.ekdawn.com (mail.ekdawn.com [159.69.120.39]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mailin029.protonmail.ch (Postfix) with ESMTPS id 4YnZQK5gSPz9vNwd for ; Tue, 4 Feb 2025 20:16:41 + (UTC) Received: from [10.60.137.132] (gw9.ff3l.net [144.76.31.247]) by mail.ekdawn.com (Postfix) with ESMTPSA id B43D01834A7 for ; Tue, 04 Feb 2025 20:15:26 + (UTC) Dkim-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=horse64.org; s=dkim1; t=1738700126; bh=g3zLYH4xKxcPrHOD18z9YfpQcnk/GaJedfustWU5uGs=; h=Message-ID:Date:To:From:Subject:From:Sender:To:CC:Subject: Message-Id:Date; b=1lDE0gJJ7nY1RojzH3YusanCRbu8McLna34WD3RJzEEii8RRpqxo/as9ZxNmpNoXS Xm3nb6a1rlnDNr7uvJYjGnc0XbUfZmonVmeooCkNjpizR/UK7fDc+QVuF8rzddl+Q+ FMxqRMRaYXCj+kr9KmnRUsp6l1XLqA/5G8u64SSn4/EZ8HcWFKoZev51o/rtctMqmC 9udFrKEiTaJGPWaZwMnfALUy2YQLzj6ZMtqmHQAwCQEwygQhxsO7Dj5FMso6qVYN3b +1SJRD9iVa7l5EJe5TcZVg1Dhz0JH4D97PJo2RL0KTninkYBC+rawdY8u08eJyLPFk BYNTlKqgn25Bsa00zNRg6IZs3qJ67DpnnxDR9I3pW2xZVlSypX6PbVb72ROINkjB3j 2qBYxGgcQDMKntKci3xIODq6MaM4g9O4u9RX2XThf5G65OnsUaFv8gS7DXNltejmI2 2z46QY+yC5nnM0iToVz1nWLf/6xdP2DEXvOL6cexp6zkq7PhTK/t5gGU/iSwGq69OZ nJ7EBYzIB5qEMlFZf7AKX+npSgJ97Z+/411+xIUBTPaKxdsTnHs047dBczAyF98gCT DgZk96nF6M59RQ0vQZMjaaGV0c9l/7Jnh4N4biRqC9UDRH6K6tBI/Ot9grWock3fbQ 0Yvi34uAVC7V3Rot4G8709q4= Message-Id: Date: Tue, 04 Feb 2025 21:16:34 +0100 Mime-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: mylittletestm...@proton.me From: ellie Subject: test ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: IP discard for authenticated e-mails
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_security_level=encrypt
-o { header_checks=regexp:/etc/postfix/header_checks_incoming }
submission inet n - n - - smtpd
-o syslog_name=postfix/submission
-o smtpd_tls_security_level=encrypt
-o smtpd_tls_auth_only=yes
-o local_header_rewrite_clients=static:all
-o { smtp_header_checks = pcre:{{/^Received:/ IGNORE}} }
-o {
smtpd_recipient_restrictions=reject_unknown_sender_domain,reject_invalid_helo_hostname,reject_unknown_helo_hostname,permit_sasl_authenticated,permit_mynetworks,reject
}
-o smtpd_reject_unlisted_recipient=no
-o smtpd_client_restrictions=
-o smtpd_helo_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_relay_restrictions=
-o milter_macro_daemon_name=ORIGINATING
Sadly, this doesn't seem to work on my setup either. But it seems like a
nice solution, if it can be made to work. :-O But a dedicated named
toggle might also have benefits, like making it even easier to find.
Regards,
ell1e
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Feature: IP discard for authenticated e-mails
On 2/5/25 5:57 PM, Wietse Venema via Postfix-users wrote: The following is now part of Postfix 3.10, which is back in the code freeze stage. Thank you so much for working on this, this is amazing!! Regards, ell1e ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: X-Original-Delivered-To or X-Envelope-To?
Thank you so much for the in-depth response!! On 2/6/25 7:10 PM, Wietse Venema via Postfix-users wrote: You should not prepend the header with multi-recipient deliveries, because that is a privacy problem. I wonder, what happens with your config in this case? Would it omit the X-Original-To header, or would it omit some of the delivery targets? Both seem somewhat unfortunate for some uses, e.g. if I ever gave somebody else an email alias to forward, and somebody CC'ed us both. Wouldn't it in theory be possible to have no privacy leaks? E.g. for forwards: a...@example.com -> john...@oops.example.com, a...@example.com -> john...@oops.example.com, a...@example.com -> lisa...@differenthost.example.com and then a mail CCing abc@, abc2@, abc3@, I guess the header would ideally show the first to for johndoe, and only the last for lisafoo. Sorry if I'm overthinking here... Regards, ell1e ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] X-Original-Delivered-To or X-Envelope-To?
Dear postfix users community, Sorry for asking another beginner question. I've seen solutions online for this, but only one with caveats. One of my setups involves a forwarding SMTP that handles external domains, that then forwards them to some other internal mailbox on a different machine. To do that, I use postfix with virtual_alias_maps to forward it. I've seen that use case also used to implement catch-alls. The problem: postfix sets Delivered-To for the final target address it forwards to. However, it doesn't seem to keep the original envelope-to. I've seen this solution float around: main.cf: smtpd_recipient_restrictions = [...], check_recipient_access pcre:/etc/postfix/prepend_header /etc/postfix/prepend_header: /(.+)/PREPEND X-Envelope-To: $1 However, that seems to cause problems when e.g. the original mail was sent to multiple inboxes at once, e.g. via BCC to multiple ones, and seems to result in duplicate X-Envelope-To headers. (To be honest I haven't tried it myself, but I've seen complaints claiming that.) So is there some nice canonical solution? Regards, ell1e ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: X-Original-Delivered-To or X-Envelope-To?
On 2/6/25 7:10 PM, Wietse Venema via Postfix-users wrote: You can force this witH; /etc/postfix/master.cf relay .. .. .. .. .. .. smtp flags=O /etc/postfix/main.cf: relay_destination_recipient_limit = 1 transport_maps = hash:/etc/postfix/transport /etc/postfix/transport example.com relay:[internal-mailhub.example] Since I use virtual_alias_maps rather than relaying entire domains as relay_domains apparently would do, I haven't quite wrapped my head around yet how this interacts. If anybody else finds it interesting, this *doesn't* work: /etc/postfix/master.cf virtual .. .. .. .. .. .. virtual flags=O relay .. .. .. .. .. .. smtp flags=O /etc/postfix/main.cf: virtual_destination_recipient_limit = 1 relay_destination_recipient_limit=1 virtual_alias_domains = ... virtual_alias_maps = lmdb:/etc/postfix/virtual Regards, ell1e ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
