#
# =============================================================================
# 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_maj] |, CLEAN (other)||, TEMPFAIL\
|, OVERSIZED message\
|, invalid header[?[:ccat_min]||: bad MIME|: unencoded 8-bit character\
|: improper use of control char|: all-whitespace 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]
]
[? %#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
[? %#X ||[? [:ccat_min]
|INVALID HEADER
|INVALID HEADER: BAD MIME HEADERS OR BAD MIME STRUCTURE
|INVALID HEADER: INVALID 8-BIT CHARACTERS IN HEADER
|INVALID HEADER: INVALID CONTROL CHARACTERS IN HEADER
|INVALID HEADER: FOLDED HEADER FIELD MADE UP ENTIRELY OF WHITESPACE
|INVALID HEADER: HEADER LINE LONGER THAN RFC2822 LIMIT OF 998 CHARACTERS
|INVALID HEADER
]
[[:wrap|78|  |  |%X]\n]
]\
#[? %a |#|[:wrap|78||  |First upstream SMTP client IP address: \[%a\] %g]]
#[? %e |#|[:wrap|78||  |According to a 'Received:' trace,\
# the message originated at: \[%e\], %t]]
[? %s |#|[:wrap|78||  |Return-Path: %s]]
[? %m |#|[:wrap|78||  |Message-ID: %m]]
[? %r |#|[:wrap|78||  |Resent-Message-ID: %r]]
[? %j |#|[:wrap|78||  |Subject: %j]]

# ccat_min 0: other,  1: bad MIME,  2: 8-bit char,  3: NUL/CR,
#          4: empty,  5: long,  6: syntax
[? %#X ||[? [:ccat_min]
|# 0: other
|# 1: bad MIME
|# 2: 8-bit char
WHAT IS AN INVALID CHARACTER IN MAIL HEADER?

  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 mail header.

  If such characters (e.g. with diacritics) from ISO Latin or other
  alphabets need to be included in the header, these characters need
  to be properly encoded according to RFC 2047. This encoding is often
  done transparently by mail reader (MUA), but if automatic encoding is
  not available (e.g. by some older MUA) it is the user's responsibility
  to avoid the use of such characters in mail header, or to encode them
  manually. Typically the offending header fields in this category are
  'Subject', 'Organization', and comment fields in e-mail addresses of
  the 'From', 'To' and 'Cc'.

  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.
#
[~[:x-mailer]|^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 MESSAGE HEADER

  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 mail header.
|# 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
|# other
]]#
