The list server is configured to reject mail that fails DKIM or SPF checks. It is not supposed to receive mail from other list servers or forwarding services so there's no reason for mail to fail such checks. If you have a problem with mail from your ISP going to the list then contact me off-list and I'll help you file a bug report. If you have a problem with your own personal domain then I am happy to send you log entries related to your issue and help you debug it. Don't claim that there's something wrong with the LUV server though. If you setup your server to DKIM sign mail and it doesn't do it correctly or setup a SPF entry that doesn't include your sending address then it's your issue. I'm happy to help you solve your issues, just don't claim that they are my issues. While we are having a debate about whether list servers should send out mail that fails DKIM and/or SPF checks I think that there is no reason that a mail server should receive such mail unless it is configured to receive mail from another list server. Of course if a list server receives mail from another list server it should be configured to whitelist such mail. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
On Tue, 22 Dec 2015 03:50:54 PM Russell Coker via luv-main wrote:
Don't claim that there's something wrong with the LUV server though.
I'm not, RFC-2822 "Internet Message Format" is (IMHO): # [...] The "From:" field specifies the author(s) of the message, # that is, the mailbox(es) of the person(s) or system(s) responsible # for the writing of the message. The "Sender:" field specifies the # mailbox of the agent responsible for the actual transmission of the # message. It appears to me that what should go in the Sender: field is instead ending up in the From: field and that seems to be in clear breach of the RFC. All the best, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC
On Tue, 22 Dec 2015 11:20:54 PM Chris Samuel via luv-main wrote:
On Tue, 22 Dec 2015 03:50:54 PM Russell Coker via luv-main wrote:
The list server is configured to reject mail that fails DKIM or SPF checks. It is not supposed to receive mail from other list servers or forwarding services so there's no reason for mail to fail such checks.
If you have a problem with mail from your ISP going to the list then contact me off-list and I'll help you file a bug report.
If you have a problem with your own personal domain then I am happy to send you log entries related to your issue and help you debug it.
Don't claim that there's something wrong with the LUV server though.
I'm not, RFC-2822 "Internet Message Format" is (IMHO):
# [...] The "From:" field specifies the author(s) of the message, # that is, the mailbox(es) of the person(s) or system(s) responsible # for the writing of the message. The "Sender:" field specifies the # mailbox of the agent responsible for the actual transmission of the # message.
It appears to me that what should go in the Sender: field is instead ending up in the From: field and that seems to be in clear breach of the RFC.
Chris, my entire point here is to not mix up the issues of DKIM/SPF checks on receipt and the issue of how the From: field is used. No mail has been rejected due to changes to the From: field. Some mail has been rejected because it doesn't pass DKIM/SPF checks. When someone's mail is rejected due to DKIM/SPF failures then I'm happy to help diagnose that problem. But it's not related to mailing list changes. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
On Wed, Dec 23, 2015 at 12:25:31AM +1100, Russell Coker wrote:
No mail has been rejected due to changes to the From: field.
Yes, but many, including myself; are frustrated by how their MUA behaves as a result, and some even resorting to custom procmail rules to work around it. Could you please disable from_as_list? As dmarc_moderation_action would suffice.
Quoting Joel W. Shea via luv-main (luv-main@luv.asn.au):
Yes, but many, including myself; are frustrated by how their MUA behaves as a result, and some even resorting to custom procmail rules to work around it.
Anyone care to share a tested procmail recipe to (locally here, after receipt) retroactively correct From: to what the sender specified, then remove the spurious MLM-added Reply-To: line? Thanks in advance. -- Cheers, He's making a database; Rick Moen He's sorting it twice. rick@linuxmafia.com SELECT * from contacts WHERE behavior = 'nice' McQ! (4x80) SQL Clause is coming to town. -- @KarenMN
On Wed, Dec 23, 2015 at 04:10:04AM -0800, Rick Moen via luv-main wrote:
Quoting Joel W. Shea via luv-main (luv-main@luv.asn.au):
Yes, but many, including myself; are frustrated by how their MUA behaves as a result, and some even resorting to custom procmail rules to work around it.
Anyone care to share a tested procmail recipe to (locally here, after receipt) retroactively correct From: to what the sender specified, then remove the spurious MLM-added Reply-To: line? Thanks in advance.
I don't have a working and tested rule but it should be possible to get procmail to: 1. delete the From: header 2. rename the Reply-To: header to From: Unfortunately, there's no way of restoring any original Reply-To header - the list is now configured to destroy that. in my case, I already have a rule from years ago renaming Reply-To to X-Old-Reply-To to reduce the annoyance of previous manifestations of Reply-To munging abominations: # rename Reply-To header :0 fhw | /usr/bin/formail -R Reply-To X-Old-Reply-To Without testing, i'd guess that renaming Reply-To: to From: could be: # rename Reply-To: header to From: :0 fhw * (^TO|^FROM|^FROM_DAEMON|^Sender:|^X-Been-There:|^List-[^:]*:).*@(lists.)?luv\.asn\.au | /usr/bin/formail -R Reply-To From -U From or possibly: | /usr/bin/formail -R Reply-To From | /usr/bin/formail -U From (i.e. rename Reply-To to From, and then delete all but the *last* From: header) craig -- craig sanders <cas@taz.net.au>
Quoting Craig Sanders (cas@taz.net.au):
Without testing, i'd guess that renaming Reply-To: to From: could be:
# rename Reply-To: header to From: :0 fhw * (^TO|^FROM|^FROM_DAEMON|^Sender:|^X-Been-There:|^List-[^:]*:).*@(lists.)?luv\.asn\.au | /usr/bin/formail -R Reply-To From -U From
Seems to work a treat, thanks! I particularly like that my attribution string (as above) is back to being correct. -- Cheers, <blazemore> omg i love this song Rick Moen <blazemore> Now playing: Unknown Artist - Track 2 rick@linuxmafia.com @ 128 Kbps. (0:47/3:24) McQ! (4x80) <Javi> blazemore: Yeah, that's a bad-ass song.
On Wed, Dec 23, 2015 at 07:03:48PM -0800, Rick Moen via luv-main wrote:
Without testing, i'd guess that renaming Reply-To: to From: could be:
# rename Reply-To: header to From: :0 fhw * (^TO|^FROM|^FROM_DAEMON|^Sender:|^X-Been-There:|^List-[^:]*:).*@(lists.)?luv\.asn\.au | /usr/bin/formail -R Reply-To From -U From
Seems to work a treat, thanks!
I particularly like that my attribution string (as above) is back to being correct.
thanks Mr guinea-pig, now that i know it works i'll use it myself :-) craig Research Fellow, Evil Mad Scientists Pty. Ltd. (who needs an ethics committee anyway) -- craig sanders <cas@taz.net.au>
On Wed, 23 Dec 2015 12:25:31 AM Russell Coker via luv-main wrote:
No mail has been rejected due to changes to the From: field.
Great, so that change will be reverted to make it RFC compliant once more? -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC
participants (5)
-
Chris Samuel -
Craig Sanders -
Joel W. Shea -
Rick Moen -
Russell Coker