/etc/amavis/en_US/template-dsn.txt is in amavisd-new 1:2.6.5-0ubuntu3.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 | #
# =============================================================================
# This is a template for (neutral: non-virus, non-spam, non-banned)
# DELIVERY STATUS NOTIFICATIONS to sender.
# For syntax and customization instructions see README.customize.
# The From, To and Date header fields will be provided automatically.
# Long header fields will be automatically wrapped by the program.
#
Subject: [?%#D|Undeliverable mail|Delivery status notification]\
[? [:ccat|major] |||, MTA-BLOCKED\
|, OVERSIZED message\
|, invalid header[=explain_badh|1]\
[?[:ccat|minor]||: bad MIME|: unencoded 8-bit character\
|: improper use of control char|: all-whitespace header field\
|: header line longer than 998 characters|: header field syntax error\
|: missing required header field|: duplicate header field|]\
|, UNSOLICITED BULK EMAIL apparently from you\
|, UNSOLICITED BULK EMAIL apparently from you\
|, contents UNCHECKED\
|, BANNED contents type (%F)\
|, VIRUS in message apparently from you (%V)\
]
Message-ID: <DSN%i@%h>
[? %#D |#|Your message WAS SUCCESSFULLY RELAYED to:[\n %D]
[~[:dsn_notify]|["\\bSUCCESS\\b"]|\
and you explicitly requested a delivery status notification on success.\n]\
]
[? %#N |#|The message WAS NOT relayed to:[\n %N]
]
[:wrap|78|||This [?%#D|nondelivery|delivery] report was \
generated by the program amavisd-new at host %h. \
Our internal reference code for your message is %n/%i]
# ccat_min 0: other, 1: bad MIME, 2: 8-bit char, 3: NUL/CR,
# 4: empty, 5: long, 6: syntax, 7: missing, 8: multiple
[? [:explain_badh] ||[? [:ccat|minor]
|INVALID HEADER
|INVALID HEADER: BAD MIME HEADER SECTION OR BAD MIME STRUCTURE
|INVALID HEADER: INVALID 8-BIT CHARACTERS IN HEADER SECTION
|INVALID HEADER: INVALID CONTROL CHARACTERS IN HEADER SECTION
|INVALID HEADER: FOLDED HEADER FIELD MADE UP ENTIRELY OF WHITESPACE
|INVALID HEADER: HEADER LINE LONGER THAN RFC2822 LIMIT OF 998 CHARACTERS
|INVALID HEADER: HEADER FIELD SYNTAX ERROR
|INVALID HEADER: MISSING REQUIRED HEADER FIELD
|INVALID HEADER: DUPLICATE HEADER FIELD
|INVALID HEADER
]
[[:wrap|78| | |%X]\n]
]\
#
[:wrap|78|| |Return-Path: %s[?[:dkim|envsender]|| (OK)]]
[:wrap|78|| |From: [:header_field|From|100][?[:dkim|author]|| (dkim:AUTHOR)]]
[? [:header_field|Sender]|#|\
[:wrap|78|| |Sender: [:header_field|Sender|100]\
[?[:dkim|sender]|| (dkim:SENDER)]]]
[? %m |#|[:wrap|78|| |Message-ID: %m]]
[? %r |#|[:wrap|78|| |Resent-Message-ID: %r]]
[? %#X|#|[? [:useragent] |#|[:wrap|78|| |[:useragent]]]]
[? %j |#|[:wrap|78|| |Subject: [:header_field|Subject|100]]]
# ccat_min 0: other, 1: bad MIME, 2: 8-bit char, 3: NUL/CR,
# 4: empty, 5: long, 6: syntax, 7: missing, 8: multiple
[? [:explain_badh] ||[? [:ccat|minor]
|# 0: other
|# 1: bad MIME
|# 2: 8-bit char
WHAT IS AN INVALID CHARACTER IN A MAIL HEADER SECTION?
The RFC 2822 standard specifies rules for forming internet messages.
It does not allow the use of characters with codes above 127 to be
used directly (non-encoded) in a mail header section.
If such characters (e.g. with diacritics) from ISO Latin or other
alphabets need to be included in a header section, these characters
need to be properly encoded according to RFC 2047. Such encoding is
often done transparently by mail reader (MUA), but if automatic
encoding is not available (e.g. by some older MUA) it is a user's
responsibility to avoid using such characters in a header section,
or to encode them manually. Typically the offending header fields
in this category are 'Subject', 'Organization', and comment fields
in e-mail addresses of 'From', 'To' or 'Cc' header fields.
Sometimes such invalid header fields are inserted automatically
by some MUA, MTA, content checker, or other mail handling service.
If this is the case, that service needs to be fixed or properly
configured. Typically the offending header fields in this category
are 'Date', 'Received', 'X-Mailer', 'X-Priority', 'X-Scanned', etc.
If you don't know how to fix or avoid the problem, please report it
to _your_ postmaster or system manager.
#
[~[:useragent]|^X-Mailer:\\s*Microsoft Outlook Express 6\\.00|["
If using Microsoft Outlook Express as your MUA, make sure its
settings under:
Tools -> Options -> Send -> Mail Sending Format -> Plain & HTML
are: "MIME format" MUST BE selected,
and "Allow 8-bit characters in headers" MUST NOT be enabled!
"]]#
|# 3: NUL/CR
IMPROPER USE OF CONTROL CHARACTER IN A MESSAGE HEADER SECTION
The RFC 2822 standard specifies rules for forming internet messages.
It does not allow the use of control characters NUL and bare CR
to be used directly in a mail header section.
|# 4: empty
IMPROPER FOLDED HEADER FIELD MADE UP ENTIRELY OF WHITESPACE
The RFC 2822 standard specifies rules for forming internet messages.
In section '3.2.3. Folding white space and comments' it explicitly
prohibits folding of header fields in such a way that any line of a
folded header field is made up entirely of white-space characters
(control characters SP and HTAB) and nothing else.
|# 5: long
HEADER LINE LONGER THAN RFC2822 LIMIT OF 998 CHARACTERS
The RFC 2822 standard specifies rules for forming internet messages.
Section '2.1.1. Line Length Limits' prohibits each line of a header
to be more than 998 characters in length (excluding the CRLF).
|# 6: syntax
|# 7: missing
MISSING REQUIRED HEADER FIELD
The RFC 2822 standard specifies rules for forming internet messages.
Section '3.6. Field definitions' specifies that certain header fields
are required (origination date field and the originator address field).
|# 8: multiple
DUPLICATE HEADER FIELD
The RFC 2822 standard specifies rules for forming internet messages.
Section '3.6. Field definitions' specifies that certain header fields
must not occur more than once in a message header section.
|# other
]]#
|