"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.

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

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:joe@gmail.com               NO-QUICK
RejectShortMsgsTo:Joe.Denver@domain.com         NO

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 :

DROP_DELIVERY_NOTIFICATION_REQUEST   YES

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

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.