[pfx] Re: Documentation - SASL_README
James Feeney via Postfix-users: > If I am now understanding correctly: > > > The "smtpd_sasl_auth_enable=yes" configuration parameter for > accessing "smtpd submissions", in master.cf, is *entirely distinct* > from the "smtpd_relay_restrictions = permit_sasl_authenticated" > configuration parameter, I don't see "entirely" or "distinct" in Postfix SASL documentation. Here is the relationship: 1) smtpd_relay_restrictions grants relay permission. 2) "smtpd_relay_restrictions = permit_sasl_authenticated" requires that an SMTP client uses SASL authentication. 3) permit_sasl_authenticated requires that SASL authentication is enabled with "smtpd_sasl_auth_enable=yes". > Since I was rather confused on this point, and confused by the log > message - checking and rechecking the SASL configuration, in > futility - other people might be as well. > > Perhaps a bold print "Important" notice with the above text, or > something similar, could be added to > https://www.postfix.org/SASL_README.html under the section "Enabling > SASL authorization in the Postfix SMTP server". As the title says, this enables SASL authentication and authorization. It does not give permission to relay. An SMTP client still has to SASL authentication before they have "permit_sasl_authenticated" privileges. > And/or, the log message could be made in stages, to distinguish > explicitly whether the failure occurred with the master.cf "smtpd > submissions" check or with the main.cf "smtp relay" check. With Postfix 2.9 and later, master.cf is configured so that a Postfix submission-like SMTP server logs its name as: postfix/submission/smtpd postfix/submissions/smtpd postfix/smtps/smtpd That includes the logging where a submission-like SMTP server rejects relay permission. > I know this may seem obvious in retrospect, and the SASL_README already says > explicitly - though without emphasis - that: > > After the client has authenticated with SASL, the Postfix SMTP server > decides what the remote SMTP client will be authorized for. ... These > permissions are not enabled by default. > > that language, to my mind, does not really convey the significance > of this configuration parameter in main.cf, *in addition to* the > configuration in master.cf, or the frustrating consequence of > failing to configure this parameter properly. It is not unusual that the use of featrure X (in this case, permit_sasl_authenticated or reject sender_login_mismatch) requires that the feature is first enabled (in this case with smtpd_sasl_auth_enable). Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Mail Being Rejected by ISP
On 10/21/2024 6:36 PM, Bill Cole via Postfix-users wrote: On 2024-10-21 at 16:43:05 UTC-0400 (Mon, 21 Oct 2024 16:43:05 -0400) Steve Matzura via Postfix-users is rumored to have said: [ big snip...] Here's a returned mail message I received when I tried to simply send a message to myself. This shows me no mail is going out at all. I actually was [...] : host mail.gandi.net[217.70.178.9] said: 554 5.7.1 : Client host rejected: Access denied (in reply to RCPT TO command) This is how the DNS for your mail server looks from here: # host 92.243.26.209 209.26.243.92.in-addr.arpa domain name pointer xvm-26-209.sd6.ghst.net. # host xvm-26-209.sd6.ghst.net. Host xvm-26-209.sd6.ghst.net. not found: 3(NXDOMAIN) This is a typical pattern for compromised hosts which send spam and other bad traffic. The PTR returns a name which is clearly derived from the IP and which does not itself resolve. Very sketchy. As this appears to be a Gandi IP address and you're talking to a Gandi machine, which is giving you a policy prohibition (5.7.1) error code. Talk to Gandi. If you're sending mail, even through a smarthost, you should have a REAL name, not something invented by your host. I suspect that you or they must fix your DNS so that both your IPv4 and IPv6 addresses have "reverse DNS" (PTR records) resolving to a name which has forward (A and ) DNS records resolving that name back to the same network addresses. You should also use that name as your smtp_helo_name, which by default is set equal to $myhostname. It is not possible to say for sure what changed to make this happen, as it could be entirely internal to Gandi. b...@scconsult.com orbillc...@apache.org (AKA @grumpybozo@toad.social and many *@billmail.scconsult.com addresses) Not Currently Available For Hire I just put in a detailed support ticket with Gandi. Considering my email was working up until Saturday midday UTC, I'm assuming--presuming--this one's on them.___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: reverse DMARC protection by restoring the "From:" header?
Wietse Venema via Postfix-users wrote in
<4xxvvh0xgwzj...@spike.porcupine.org>:
|Vincent Lefevre via Postfix-users:
|[ Charset ISO-8859-1 converted... ]
|> As DMARC protection, some mailing-lists (like postfix-users)
|> rewrite the "From:" header, with at least 2 drawbacks:
|> * This breaks e-mail searching by the "From:" address.
|> * At my work, only the address is changed (without introducing
|> "via "), so that this is very confusing as mail
|> appears like
|> From: Firstname Lastname
|> and we start seeing users sending private mail to mailing-lists
|> because they did not notice that the address changed.
|
|The "via listname" part is there for a good reason - it is to prevent
|human mistakes like the one you describe.
|
|If something removes "via listname" from postfix-users messages,
|that would be a terrible mistake, and they should stop doing that.
|
|> I was wondering whether I could ask postfix to revert the "From:"
|> header back to the original value, just before the local delivery,
|> at least for lists that keep the original address in some other
|> header ("X-MailFrom:" for postfix-users, "X-Original-From:" for
|> some mailing-lists...). Any idea?
|
|No, but you're welcome to contribute a content filter (Milter) that
|does this. A Milter can be implemented in many programming languages,
|and would work like this:
|
|- Look at each SMFIC_RCPT event and see if the recipient domain is
|local (a configurable list of domains).
|
|- Look at each SMFIC_HEADER event, and see if it is an "X-MailFrom:"
|or "X-Original-From:" header (a configurable list of labels).
That is what Author: is meant for btw.
|- When receiving an SMFIC_EOH (end of headers) event, if there was
|no "From: XXX via YYY" header, replace From: with content from
|"X-MailFrom:" or "X-Original-From:".
In general it is surely only a user interface question if Author:
would finally be adopted.
--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)
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Spaces in Master.cf values
postfix--- via Postfix-users:
> Spaces are not allowed in submission -o override settings.
> How do you handle adding a service? Or is it not possible? Can you \ the
> space?
>
> -o smtpd_client_restrictions=check_policy_service\ unix:private/myservice
Use
-o { smtpd_client_restrictions = check_policy_service
unix:private/myservice }
Supported in Postfix 3.0 and later.
https://www.postfix.org/master.5.html#syntax
Wietse
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Spaces in Master.cf values
Spaces are not allowed in submission -o override settings. How do you handle adding a service? Or is it not possible? Can you \ the space? -o smtpd_client_restrictions=check_policy_service\ unix:private/myservice ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Spaces in Master.cf values
* postfix--- via Postfix-users: > Spaces are not allowed in submission -o override settings. > How do you handle adding a service? You can use commas as separators. -Ralph ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Spaces in Master.cf values
On 23/10/24 08:56, postfix--- via Postfix-users wrote:
Spaces are not allowed in submission -o override settings.
How do you handle adding a service? Or is it not possible? Can you \ the
space?
-o smtpd_client_restrictions=check_policy_service\
unix:private/myservice
You can set a variable in main.cf and use that variable here, e.g.:
main.cf:
mua_client_restrictions = check_policy_service unix:private/myservice
master.cf:
-o smtpd_client_restrictions=$mua_client_restrictions
You can use {} to encapsulate settings that have whitespace in them, e.g.:
-o { smtpd_client_restrictions = check_policy_service
unix:private/myservice }
Peter
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Documentation - SASL_README
If I am now understanding correctly: The "smtpd_sasl_auth_enable=yes" configuration parameter for accessing "smtpd submissions", in master.cf, is *entirely distinct* from the "smtpd_relay_restrictions = permit_sasl_authenticated" configuration parameter, which subsequently allows access to "smtp relay", in main.cf. To send mail using sasl authentication, *both* checks, or smtpd sasl and some other "smtp relay" check, have to succeed. Otherwise, the smtpd log will only show "warning: SASL authentication failure: Password verification failed", even when the failure actually occurred with the "smtp relay" check, and not with the "smtpd submissions" check. Since I was rather confused on this point, and confused by the log message - checking and rechecking the SASL configuration, in futility - other people might be as well. Perhaps a bold print "Important" notice with the above text, or something similar, could be added to https://www.postfix.org/SASL_README.html under the section "Enabling SASL authorization in the Postfix SMTP server". And/or, the log message could be made in stages, to distinguish explicitly whether the failure occurred with the master.cf "smtpd submissions" check or with the main.cf "smtp relay" check. I know this may seem obvious in retrospect, and the SASL_README already says explicitly - though without emphasis - that: After the client has authenticated with SASL, the Postfix SMTP server decides what the remote SMTP client will be authorized for. ... These permissions are not enabled by default. that language, to my mind, does not really convey the significance of this configuration parameter in main.cf, *in addition to* the configuration in master.cf, or the frustrating consequence of failing to configure this parameter properly. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Documentation - SASL_README
On Tue, 2024-10-22 at 15:30 -0400, Wietse Venema via Postfix-users wrote: > James Feeney via Postfix-users: > > If I am now understanding correctly: > > > > > > The "smtpd_sasl_auth_enable=yes" configuration parameter for > > accessing "smtpd submissions", in master.cf, is *entirely distinct* > > from the "smtpd_relay_restrictions = permit_sasl_authenticated" > > configuration parameter, > > I don't see "entirely" or "distinct" in Postfix SASL documentation. > Yeah. That's a problem with the SASL_README, where it fails to really bring-out this issue. > > > Since I was rather confused on this point, and confused by the log > > message - checking and rechecking the SASL configuration, in > > futility - other people might be as well. > > > > Perhaps a bold print "Important" notice with the above text, or > > something similar, could be added to > > https://www.postfix.org/SASL_README.html under the section "Enabling > > SASL authorization in the Postfix SMTP server". > > As the title says, this enables SASL authentication and authorization. > It does not give permission to relay. An SMTP client still has to > SASL authentication before they have "permit_sasl_authenticated" > privileges. > And, the reverse. An SMTP client also *has* to have relay privileges, such as "permit_sasl_authenticated" or "permit_mynetworks", otherwise, "smtpd_sasl_auth_enable" is useless. That is the point here. Maybe I was not being clear about this? Of course, the "client" in this case is actually not an "smtp client", on port 25, when it is instead a "submissions client". on port 465. > > > With Postfix 2.9 and later, master.cf is configured so that a Postfix > submission-like SMTP server logs its name as: > > postfix/submission/smtpd > postfix/submissions/smtpd > postfix/smtps/smtpd > And that note in the log message is useless when the authentication failure is actually caused by not having relay privileges. It's the same log message, for either cause, and the user cannot tell the difference, whether the cause is a SASL configuration problem or a postfix configuration problem. James ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Mail Being Rejected by ISP
On 2024-10-22 at 10:19:26 UTC-0400 (Tue, 22 Oct 2024 10:19:26 -0400) Steve Matzura via Postfix-users is rumored to have said: On 10/21/2024 7:24 PM, Andrew Athan via Postfix-users wrote: You’ve been told about 10 times now to check your reverse dns ptr records for the ips used for outbound mail. have you done that? doesn’t look like it further you need to check your forward mx records are correct. once you’ve checked and fixed all of that there will be something new to say. [...] Indeed I have. I was the one that put them in, which fixed this problem about ten days ago. Now it's back. In fact, I even posted the AAA records on this very list. And we have tried to explain that the A and records are not all you need. See my message:<1cb0e561-f6df-43d1-9569-fa6a78b6e...@billmail.scconsult.com> from yesterday at 22:36 UTC. You also need 2 PTR records, one for your IPv4 address and one for IPv6 address. Very likely Gandi will need to do that for you, if they support custom rDNS at all, and if they do not, you should not try sending mail from their hosting. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo@toad.social and many *@billmail.scconsult.com addresses) Not Currently Available For Hire ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Documentation - SASL_README (Proposed logging enhancement)
On Tue, Oct 22, 2024 at 06:53:03PM -0600, James Feeney via Postfix-users wrote:
> > It does not give permission to relay. An SMTP client still has to
> > SASL authentication before they have "permit_sasl_authenticated"
> > privileges.
>
> And, the reverse. An SMTP client also *has* to have relay privileges,
> such as "permit_sasl_authenticated" or "permit_mynetworks", otherwise,
> "smtpd_sasl_auth_enable" is useless.
SASL authentication is of course useful only if authenticated users have
greater (or at least different) permissions than unauthenticated users.
In written works about security one often runs into the acronym "AAA",
which stands for:
1. Authentication
2. Authorisation
3. Auditing
>From that perspective, "smtpd_sasl_auth_enable" supports authentication,
but authentication alone does not and should not subsume authorisation,
one still needs to specify who's allowed to do what (some form of access
control lists).
For authorisation, you can use combinations of various primitives, such
as "permit_sasl_authenticated", "check_sasl_access",
"reject_sender_login_mismatch", ... to grant or restrict access to
relaying, use of specific envelope sender addresses, restrict delivery
to particular recipients, ...
And finally, the Postfix logs provide an audit trail.
> > With Postfix 2.9 and later, master.cf is configured so that a Postfix
> > submission-like SMTP server logs its name as:
> >
> > postfix/submission/smtpd
> > postfix/submissions/smtpd
> > postfix/smtps/smtpd
> >
>
> And that note in the log message is useless when the authentication
> failure is actually caused by not having relay privileges. It's the
> same log message, for either cause, and the user cannot tell the
> difference, whether the cause is a SASL configuration problem or a
> postfix configuration problem.
The above is of course nonsense, not having relay access is an
*authorisation* failure, not an authentication failure. Whether
the client is authenticated or not is logged at the start of
the mail transaction, along with the queue id:
Oct 20 15:12:48 amnesiac postfix/submission/smtpd[900561]: A847C92B6EF:
client=unknown[...], sasl_method=GSSAPI, sasl_username=viktor
On the other hand, When an authenticated sender or recipient is rejected
prior to queue file allocation, the logs show:
Oct 23 14:19:04 amnesiac postfix/submission/smtpd[1067080]: NOQUEUE:
reject: RCPT from ...: 550 5.1.1 :
Recipient address rejected: Surely you jest;
from= to=
proto=ESMTP helo=
Oct 23 14:19:04 amnesiac postfix/submission/smtpd[1067080]:
disconnect from ... ehlo=2 starttls=1 auth=1 mail=1 rcpt=0/1 quit=1
commands=6/7
and this does not include the "sasl_username", though at the end of the
connection (after collating the logs) we see that there was a successful
"auth" command.
It is perhaps reasonable as a feature request to ask for the
"sasl_username" also be logged when rejecting SMTP commands from
authenticated users. For example, with the below patch, you'd get:
Oct 23 14:49:05 amnesiac postfix/submission/smtpd[1071938]: NOQUEUE:
reject: RCPT from ...: 550 5.1.1 :
Recipient address rejected: Surely you jest;
from= to=
proto=ESMTP
helo= sasl_method=GSSAPI sasl_username=viktor
Oct 23 14:49:05 amnesiac postfix/submission/smtpd[1071938]:
disconnect from ... ehlo=2 starttls=1 auth=1 mail=1 rcpt=0/1 quit=1
commands=6/7
--- a/src/smtpd/smtpd_check.c
+++ b/src/smtpd/smtpd_check.c
@@ -1016,6 +1016,14 @@ voidlog_whatsup(SMTPD_STATE *state, const char
*whatsup,
vstring_sprintf_append(buf, " proto=%s", state->protocol);
if (state->helo_name)
vstring_sprintf_append(buf, " helo=<%s>", state->helo_name);
+#ifdef USE_SASL_AUTH
+if (state->sasl_method)
+ vstring_sprintf_append(buf, " sasl_method=%s", state->sasl_method);
+if (state->sasl_username)
+ vstring_sprintf_append(buf, " sasl_username=%s", state->sasl_username);
+if (state->sasl_sender)
+ vstring_sprintf_append(buf, " sasl_sender=%s", state->sasl_sender);
+#endif
msg_info("%s", STR(buf));
vstring_free(buf);
}
--
VIktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Documentation - SASL_README
James Feeney via Postfix-users: > > As the title says, this enables SASL authentication and authorization. > > It does not give permission to relay. An SMTP client still has to > > SASL authentication before they have "permit_sasl_authenticated" > > privileges. > > And, the reverse. An SMTP client also *has* to have relay privileges, > such as "permit_sasl_authenticated" or "permit_mynetworks", > otherwise, "smtpd_sasl_auth_enable" is useless. That is the point > here. Maybe I was not being clear about this? Of course, the That is incorrect. Any SMTP client is allowed to send mail to Postfix, but RELAYING is restricted with permit_mynetworks, permit_sasl_authenticated, and the like. > And that note in the log message is useless when the authentication > failure is actually caused by not having relay privileges. It's That is incorrect. Relay privileges depend (through permit_mynetworks) on SASL authentication. SASL authentication does not depend on relay privileges. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Is possible with postfix to do port-based routing?
On Mon, Oct 21, 2024 at 07:16:20PM +, Etienne Gladu via Postfix-users wrote: > Thanks for the config, but it still closes the port when I try to do a test. > Anyway the task changed a bit, we have to keep the original From, but only > change the Return-Path/Reply-to for every email sent. > Also it doesn't have to be specified for each port in master.cf, so maybe > something in main.cf ? > > example: > originalSender sends a email to receiverTest > > Received: from smtpr.test.com(localhost [127.0.0.1]) > by appsjava.test.com(Postfix) with ESMTP id 58546C0202B > for ; Fri, 18 Oct 2024 14:07:37 -0400 (EDT) > Subject: test > Message-ID: <20241018180745.58546c02...@appsjava.test.com> > Date: Fri, 18 Oct 2024 14:07:37 -0400 > From: <-needs to stay like this > To: Undisclosed recipients:; > Return-Path: originalsen...@test.com > ^^^this should be "nore...@test.com" > > Everything stays the same, but the Reply-To/Return-Path is replaced to be > NoReply@ > > Is this doable ? There is no "Return-Path:" in a message in transit. This header is added by the ultimate local delivery agent during final delivery, and records the envelope sender address at that point in time. The "best" you can do for "Return-Path" is rewrite the envelope sender. As for "Reply-To", you'll probably want a milter or content filter to alter it, or add it if missing. Though perhaps a header_checks file along the lines of: header-checks: /^Reply-To:/IGNORE /^Message-Id:/ PREPEND Reply-To: ... should work, provided there's reliably already a "Message-Id:" header. You'll also want to set "nested_header_checks" empty or to something else of your choice, as you probably don't want to apply this to attached messages. Perhaps set "mime_header_checks" explicitly also, though these headers don't typically appear in that context. -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] reverse DMARC protection by restoring the "From:" header?
As DMARC protection, some mailing-lists (like postfix-users)
rewrite the "From:" header, with at least 2 drawbacks:
* This breaks e-mail searching by the "From:" address.
* At my work, only the address is changed (without introducing
"via "), so that this is very confusing as mail
appears like
From: Firstname Lastname
and we start seeing users sending private mail to mailing-lists
because they did not notice that the address changed.
I was wondering whether I could ask postfix to revert the "From:"
header back to the original value, just before the local delivery,
at least for lists that keep the original address in some other
header ("X-MailFrom:" for postfix-users, "X-Original-From:" for
some mailing-lists...). Any idea?
--
Vincent Lefèvre - Web:
[pfx] Re: Mail Being Rejected by ISP
On 10/21/2024 7:24 PM, Andrew Athan via Postfix-users wrote: You’ve been told about 10 times now to check your reverse dns ptr records for the ips used for outbound mail. have you done that? doesn’t look like it further you need to check your forward mx records are correct. once you’ve checked and fixed all of that there will be something new to say. On Oct 21, 2024, at 1:44 PM, Steve Matzura via Postfix-users wrote: On 10/21/2024 3:06 PM, Andrew Athan via Postfix-users wrote: Clearly something has changed. It may be simply that you are now routing to the isp via ipv6 instead of ipv4, for example. google how to, and check that all of your public ip (v4 and v6) that may show up as your source address when connecting to outside SMTP servers have PTR records. this will typically require you to contact your comms provider to add the PTRs if they are missing. On Oct 21, 2024, at 10:55 AM, Steve Matzura via Postfix-users wrote: On 10/21/2024 1:33 PM, Wietse Venema via Postfix-users wrote: Steve Matzura via Postfix-users: On 10/21/2024 1:14 PM, Wietse Venema via Postfix-users wrote: Steve Matzura via Postfix-users: On 10/21/2024 12:42 PM, postfix--- via Postfix-users wrote: 2024-10-21T16:29:00.942189+00:00 theglobalvoice postfix/qmgr[3900]: E53B5103176: from=<>, size=3212, nrcpt=1 (queue active) 2024-10-21T16:29:01.124528+00:00 theglobalvoice postfix/smtp[4038]: E53B5103176: to=, orig_to=, relay=mail.gandi.net[2001:4b98:e00::9]:587, delay=0.19, delays=0/0/0.09/0.09, dsn=5.7.1, status=bounced (host mail.gandi.net[2001:4b98:e00::9] said: 554 5.7.1 : Client host rejected: Access denied (in reply to RCPT TO command)) 2024-10-21T16:29:01.126915+00:00 theglobalvoice postfix/qmgr[3900]: E53B5103176: removed ^^^ No PTR or mismatch? Recent DNS change and cache issue? Mismatch where? The DNS AAA record is correct. No PTR record (NXDOMAIN). Your SMTP client IP addres 2001:4b98:dc0:43:f816:3eff:fee3:4da0 does not have a PTR record. It should have one that resolves to the name in the redcord. Has the IP address changed? Has the DNS changed? Wietse Absolutely nothing has changed. I'm the only one who even has a clue how to make these kinds of changes, and I've been away from this project for a week now. ___ Here's a returned mail message I received when I tried to simply send a message to myself. This shows me no mail is going out at all. I actually was starting to think it was a groups.io problem because that's the only mail this server sends out--a daily report on certain activity on the server. Have a look at this then: From MAILER-DAEMON Mon Oct 21 20:14:00 2024 Return-Path: <> X-Original-To: tgvpad...@theglobalvoice.info Delivered-To: tgvpad...@theglobalvoice.info Received: by theglobalvoice.info (Postfix) id 2A1D8103175; Mon, 21 Oct 2024 20:14:00 + (UTC) Date: Mon, 21 Oct 2024 20:14:00 + (UTC) From: Mail Delivery System Subject: Undelivered Mail Returned to Sender To: tgvpad...@theglobalvoice.info Auto-Submitted: auto-replied MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="BB06F1030F3.1729541640/theglobalvoice.info" Content-Transfer-Encoding: 8bit Message-Id: <20241021201400.2a1d8103...@theglobalvoice.info> This is a MIME-encapsulated message. --BB06F1030F3.1729541640/theglobalvoice.info Content-Description: Notification Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit This is the mail system at host theglobalvoice.info. I'm sorry to have to inform you that your message could not be delivered to one or more recipients. It's attached below. For further assistance, please send mail to postmaster. If you do so, please include this problem report. You can delete your own text from the attached returned message. The mail system : host mail.gandi.net[217.70.178.9] said: 554 5.7.1 : Client host rejected: Access denied (in reply to RCPT TO command) --BB06F1030F3.1729541640/theglobalvoice.info Content-Description: Delivery report Content-Type: message/delivery-status Reporting-MTA: dns; theglobalvoice.info X-Postfix-Queue-ID: BB06F1030F3 X-Postfix-Sender: rfc822; tgvpad...@theglobalvoice.info Arrival-Date: Mon, 21 Oct 2024 20:13:59 + (UTC) Final-Recipient: rfc822; s...@noisynotes.com Original-Recipient: rfc822;s...@noisynotes.com Action: failed Status: 5.7.1 Remote-MTA: dns; mail.gandi.net Diagnostic-Code: smtp; 554 5.7.1 : Client host rejected: Access denied --BB06F1030F3.1729541640/theglobalvoice.info Content-Description: Undelivered Message Content-Type: message/rfc822 Content-Transfer-Encoding: 8bit Return-Path: Received: by theglobalvoice.info (Postfix, from userid 1001) id BB06F1030F3; Mon, 21 Oct 2024 20:13:59 + (UTC) To: Subject: Hello from the Global Voice User-Agent: mail (GNU Mailutils 3.17) Date: Mon, 21 Oct 2024 20:13:59 + Message-Id: <20241021201359.bb06f103..
[pfx] Re: reverse DMARC protection by restoring the "From:" header?
Vincent Lefevre via Postfix-users:
[ Charset ISO-8859-1 converted... ]
> As DMARC protection, some mailing-lists (like postfix-users)
> rewrite the "From:" header, with at least 2 drawbacks:
> * This breaks e-mail searching by the "From:" address.
> * At my work, only the address is changed (without introducing
> "via "), so that this is very confusing as mail
> appears like
> From: Firstname Lastname
> and we start seeing users sending private mail to mailing-lists
> because they did not notice that the address changed.
The "via listname" part is there for a good reason - it is to prevent
human mistakes like the one you describe.
If something removes "via listname" from postfix-users messages,
that would be a terrible mistake, and they should stop doing that.
> I was wondering whether I could ask postfix to revert the "From:"
> header back to the original value, just before the local delivery,
> at least for lists that keep the original address in some other
> header ("X-MailFrom:" for postfix-users, "X-Original-From:" for
> some mailing-lists...). Any idea?
No, but you're welcome to contribute a content filter (Milter) that
does this. A Milter can be implemented in many programming languages,
and would work like this:
- Look at each SMFIC_RCPT event and see if the recipient domain is
local (a configurable list of domains).
- Look at each SMFIC_HEADER event, and see if it is an "X-MailFrom:"
or "X-Original-From:" header (a configurable list of labels).
- When receiving an SMFIC_EOH (end of headers) event, if there was
no "From: XXX via YYY" header, replace From: with content from
"X-MailFrom:" or "X-Original-From:".
Wietse
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
