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 *<hsantos(_at_)isdg(_dot_)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-daemon(_at_)xxxxxxxxxx(_dot_)com
To: return-address(_at_)santronics(_dot_)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