[ietf-dkim] DSN with signature replay
I am wondering or under what scenario would a DSN (bounce) agent keep the original signature in its bounce notification 5322 headers? It was a legitimate bounce for a non-delivery address. But it kept several headers from the original message in the DSN message headers: DKIM-Signature: Organization: X-Mailer: What logic is there to this? Of course, the signature was invalid. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DSN with signature replay
Sonneveld, Rolf wrote: On 04-10-10, *Hector Santos *hsan...@isdg.net wrote: I am wondering or under what scenario would a DSN (bounce) agent keep the original signature in its bounce notification 5322 headers? It was a legitimate bounce for a non-delivery address.� But it kept several headers from the original message in the DSN message headers: ��� DKIM-Signature: ��� Organization: ��� X-Mailer: What logic is there to this? RFC 3462, chapter 2. quote �� The Text/RFC822-Headers body part should contain all the RFC822 http://tools.ietf.org/html/rfc822 �� header lines from the message which caused the report.� The RFC822 http://tools.ietf.org/html/rfc822 �� headers include all lines prior to the blank line in the message. �� They include the MIME-Version and MIME Content-Headers. /quote /rolf The report does contain the original message. I speak of the actual bounce message from the mailer-daemon contain a copy of above headers: DKIM-Signature: d=santronics.com; --- copy Organization: Santronics Software, Inc. --- copy X-Mailer: wcMail v6.3.453.4 --- copy Date: Fri, 01 Oct 2010 09:18:26 -0400 From: mailer-dae...@xx.com To: return-addr...@santronics.com Subject: DELIVERY FAILURE: . The rest of the DSN body message with the message/rfc822 report attachment containing the original message was fine. Am I still missing something? -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DSN with signature replay
Very odd. It might be the same software, but what I am seeing is the bouncer doing: 1) Copies the original headers minus Received trace headers, 2) Change From: to the mailer daemon address 3) Change To: to the return path address 3) Adds headers for DSN mime parts. The only reason I am seeing this because we are signing mail now and I'm seeing the new invalid signature logging with these type of bounces. -- HLS Hector Santos wrote: Sonneveld, Rolf wrote: On 04-10-10, *Hector Santos *hsan...@isdg.net wrote: I am wondering or under what scenario would a DSN (bounce) agent keep the original signature in its bounce notification 5322 headers? It was a legitimate bounce for a non-delivery address.� But it kept several headers from the original message in the DSN message headers: ��� DKIM-Signature: ��� Organization: ��� X-Mailer: What logic is there to this? RFC 3462, chapter 2. quote �� The Text/RFC822-Headers body part should contain all the RFC822 http://tools.ietf.org/html/rfc822 �� header lines from the message which caused the report.� The RFC822 http://tools.ietf.org/html/rfc822 �� headers include all lines prior to the blank line in the message. �� They include the MIME-Version and MIME Content-Headers. /quote /rolf The report does contain the original message. I speak of the actual bounce message from the mailer-daemon contain a copy of above headers: DKIM-Signature: d=santronics.com; --- copy Organization: Santronics Software, Inc. --- copy X-Mailer: wcMail v6.3.453.4 --- copy Date: Fri, 01 Oct 2010 09:18:26 -0400 From: mailer-dae...@xx.com To: return-addr...@santronics.com Subject: DELIVERY FAILURE: . The rest of the DSN body message with the message/rfc822 report attachment containing the original message was fine. Am I still missing something? ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
