Qpsmtpd:headers
NAME
headers - validate message headers
DESCRIPTION
Checks for missing or empty values in the From or Date headers.
Make sure no singular headers are duplicated. Singular headers are:
Date From Sender Reply-To To Cc Bcc Message-Id In-Reply-To References Subject
Optionally test if the Date header is too many days in the past or future. If future or past are not defined, they are not tested.
If the remote IP is whitelisted, header validation is skipped.
As per March 2017 it has been reported some well known senders are putting multiple Message-Id. As a result we removed Message-Id from the singular_headers array. See https://bugs.contribs.org/show_bug.cgi?id=9773
CONFIGURATION
The following optional settings exist:
require
headers require [ From | Date | From,Date | From,Date,Subject,Message-ID,Received ]
A comma separated list of headers to require.
Default: From
Requiring the Date header
As of 2012, requiring a valid date header will almost certainly cause the loss of valid mail. The JavaMail sender used by some banks, photo processing services, health insurance companies, bounce senders, and others do send messages without a Date header. For this reason, and despite RFC 5322, the default is not to require Date.
However, if the date header is present, and future and/or past are defined, it will be validated.
future
The number of days in the future beyond which messages are invalid.
headers [ future 1 ]
past
The number of days in the past beyond which a message is invalid. The Date header is added by the MUA, so there are many valid reasons a message may have an older date in the header. It could have been delayed by the client, the sending server, connectivity problems, recipient server problem, recipient server configuration, etc. The past setting should take those factors into consideration.
I would be surprised if a valid message ever had a date header older than a week.
headers [ past 5 ]
reject
Determine if the connection is denied. Use the reject 0 option when first enabling the plugin, and then watch your logs to see what would have been rejected. When you are no longer concerned that valid messages will be rejected, enable with reject 1.
headers reject [ 0 | 1 ]
Default: 1
reject_type
Whether to issue a permanent or temporary rejection. The default is permanent.
headers reject_type [ temp | perm ]
Using a temporary rejection is a cautious way to enable rejections. It allows an administrator to watch for a trial period and assure no valid messages are rejected. If a deferral of valid mail is noticed, reject 0 can be set to permit the deferred message to be delivered.
Default: perm
loglevel
Adjust the quantity of logging for this plugin. See docs/logging.pod
TODO
SEE ALSO
https://tools.ietf.org/html/rfc5322
AUTHOR
2012 - Matt Simerson
ACKNOWLEDGEMENTS
based in part upon check_basicheaders by Jim Winstead Jr.
Singular headers idea from Haraka's data.rfc5322_header_checks.js by Steve Freegard
SMTP HEADERS
http://forum.unifiedemail.net/default.aspx?g=posts&t=68
From:
The eMail address, and optionally the name of the author(s). In many eMail clients not changeable except through changing account settings.
To:
The eMail address(es), and optionally name(s) of the message's recipient(s). Indicates primary recipients (multiple allowed), for secondary recipients see Cc: and Bcc: below.
Subject:
A brief summary of the topic of the message. Certain abbreviations are commonly used in the subject, including "RE:" and "FW:".
Date:
The local time and date when the message was written. Like the From: field, many email clients fill this in automatically when sending. The recipient's client may then display the time in the format and time zone local to him/her.
Message-ID:
Also an automatically generated field; used to prevent multiple delivery and for reference in In-Reply-To: (see below).
Bcc:
Blind Carbon Copy; addresses added to the SMTP delivery list but not (usually) listed in the message data, remaining invisible to other recipients.
Cc:
Carbon copy; Many eMail clients will mark eMail in your inbox differently depending on whether you are in the To: or Cc: list.
Content-Type:
Information about how the message is to be displayed, usually a MIME type.
In-Reply-To:
Message-ID of the message that this is a reply to. Used to link related messages together.
Precedence:
Commonly with values "bulk", "junk", or "list"; used to indicate that automated "vacation" or "out of office" responses should not be returned for this mail, e.g. to prevent vacation notices from being sent to all other subscribers of a mailinglist.
Received:
Tracking information generated by mail servers that have previously handled a message, in reverse order (last handler first).
References:
Message-ID of the message that this is a reply to, and the message-id of the message the previous was reply a reply to, etc.
Reply-To:
Address that should be used to reply to the message.
Sender:
Address of the actual sender acting on behalf of the author listed in the From: field (secretary, list manager, etc.).
Return-Path:
When the delivery SMTP server makes the "final delivery" of a message, it inserts a return-path line at the beginning of the mail data. Thisuse of return-path is required; mail systems MUST support it. The return-path line preserves the information in the from the MAIL command.
Error-To:
Indicates where error messages should be sent. In the absence of this line, they go to the Sender:, and absent that, the From: address.
X-*
No standard header field will ever begin with the characters "X-", so application developers are free to use them for their own purposes.
