Table of Contents
"Simple Spam Checks..."
These checks don't block a significant number of spams. They exist or as they we're requested by some user or because they can solve some specific problem. E.g. rejecting short messages or dropping Notification Delivery Requests are intended to solve a privacy issue. So, don't enable them unless you need them.
Filtering short messages
If your mail server frequently has to handle unwanted messages whose body size is very short (say, something like a dozen characters), it's possible to reject them.
This kind of messages are usually sent by people wanting to validate a list of email addresses. So, they slowly send one message per address and wait for a bounce. If the message doesn't bounce, that means that the email address is probably a valid address. Sometimes, a short code is added to the message to ease correlation between a bounced message and an email address.
REJECT_SHORT_BODIES YES MIN_BODY_LENGTH 10
- This body length is, as said, the body length, and includes all attached files, both plain text and html versions of the message, all MIME tags, …
- this feature isn't applied to messages coming from known networks
But this feature can reject some legitimate messages :
- Mail commands usually sent to Mail List Managers - ze-filter take care to try to identify some usual commands but, surely, it's impossible to identify all of them.
- Google Apps (Calendar, …) - If you've configured your account to receive notifications by email and you have no event scheduled, google will send you an empty message (probably a bug in their application).
- Very short messages sent to check if the mail server is up will be rejected.
You can partially disable this feature, declaring some exceptions at ze-policy database :
RejectShortMsgsConnect:google.com NO-QUICK RejectShortMsgsFrom:firstname.lastname@example.org NO-QUICK RejectShortMsgsTo:Joe.Denver@domain.com NO
Dropping Notification Delivery Requests
Sometimes people send messages with Notification Delivery Requests header present. This may be a privacy issue. Although most MUAs can disable automatic answering to these requests, it may sometimes be useful to disable these requests - so the message continues its normal path, but the headers asking for the reception of the message are removed from original message. To enable this feature, set the following option in ze-filter.cf file :
Bad HELO/EHLO SMTP command
MYSELF 127.0.0.1 HOSTNAME smtp.example.com REJECT_BADEHLO YES BADEHLO_CHECKS ALL
BADEHLO_CHECKS allows you to define which checks to apply to EHLO/HELO parameter. It can be a list of words defined bellow !
InvalidChar- invalid character in EHLO/HELO parameter
ForgedIP- EHLO/HELO parameter is an IPv4 address but it doesn't match the client IP address
NotBracketedIP- EHLO/HELO parameter is a non bracketed IP address
NotFQDN- EHLO/HELO parameter isn't in FQDN format
IdentityTheft- SMTP client presents as being myself (my identities are defined by MYSELF configuration option)
ALL- all checks above
NONE- none of above checks
Bad date (in the future or in the past)
ze-filter can be configured to reject messages if the date in the “Date” header is more than 48 hours ahead in the future or more than a year in the past.
CHECK_DATE_IN_FUTURE YES CHECK_DATE_IN_PAST YES
Dates in the future is a trick used by spammers to be sure their messages will appear in the top of your unread messages (as they are usually sorted by date). Dates in the past reflects, most of the time, a misconfigured clock or a bad date coding format.
Rejecting too older messages can cause false positives :
- someone can bounce (bounce, not forward) an old message he finds interesting.
- some servers continue to retry old tempfailed messages during much long time (a month and even more), instead of returning them to the sender after the usual 4-5 days.
Also, it's not unusual to see dates in a format which doesn't respect RFC 2822 defined format.