Oliver, > As i study the source i found out that "user" > notifications are handled by 'delivery_status_notification' and admin > notifications handled somewhere else.
Right. But in both cases the first (or only) plain-text portion of the notification comes from its corresponding template (by calling sub expand) and these templates contain (or not contain) a %H macro call, which (if present) expands to original mail header. Removing the %H from each template makes the header inclusion in the first (or only) part of notification the go away. The delivery_status_notification routine, besides taking the expanded template and placing it as a first item in MIME tree, also appends two more DSN MIME components, as per rfc3462/rfc3464. This only applies to sender notififications, but not to recipient and admin notifications, as there are not governed by these RFCs. > In the former of both, the original mail-header (contained by %H > macro) is hard-coded and does not depend on the existence of this macro. This only holds true for third DSN mime part as per rfc3462/rfc3464. > Also the "From" "To" and "Date" fields cannot be set by the template > because they will be forced to some other value in this sub. Right. This change was made to overcome problems with proper placement of these headers when Resent-* header fields also need to be inserted. So far I don't think it's a big sacrifice. Redesigning templates to support MIME structure and other bells is on a to-do list, but not high on priority. > I got familar with the macro processor (expand()), but i think it > would be much clearer if there are different templates for "BANNED" > "HEADER FAILURE" and "VIRUS" indications. Is there a chance to do this? It might be cleaner. It evolved this way through a series of small changes through the history. At the moment I have other worries with 2.4.0, so don't hold your breath. > You're right about the RFC, but our customers don't know anything > about this. And they don't worry if it's missing. But MUA know about these, and don't bother reader with them unless necessary/requested. > But they worry if > there is a Mail with massive information that they don't understand > and likely to erase the message instead of reading it. > I don't want to create a new thread about whether or not RFC > conventions should be strict or not. I just decided not to do so in > that special case. Edit delivery_status_notification if necessary. Admittedly the third part of DSN (RFC3462) is optional, so by removing it the NDN would still be standards compliant. I'll consider it when I'll be implementing the full DSN support, planned for 2.4.0. Checking the Postfix bounce(8) man page and the sendmail PrivacyOptions I only see option to restrict mail body inclusion in bounces, but no controls over mail header inclusion in DSN. Until these two most popular mailers offer such option, I don't see pressing need for amavisd-new to outsmart them and be more flexible. > So it would be very fine if one could decide if the message-header is > to be included by using %H in his template. You are refering to the third item in the DSN (RFC 3462) MIME structure, not to the first part (the plain-text one), where %H does have a full control. Mark ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ AMaViS-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/amavis-user AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3 AMaViS-HowTos:http://www.amavis.org/howto/
