Envelope Scan Options

Top  Previous  Next



The message "Envelope" is information your normally do not see in the message headers. When a remote mail server wants to send your mail server a message, it requests a connection and then a conversation takes place between the two servers. This conversation takes place as follows:


1.The remote server will request a connection.
2.Your server will respond and tell the remote server that it is ready.
3.The remote server will then issue an HELO command identifying itself. This is normally the public HOST NAME of the remote computer. If the sender has defined a public reverse DNS (REVDNS) entry, it may also be the same as the HELO command identifier. The formatting of this command is important and can actually tell you quite a bit about the sender. It is frequently possible to identify the sender as a spammer simply based on this command.
4.Your server will then respond with an OK command telling the remote server to proceed.
5.The remote server will then send a MAIL FROM command telling your server who the message is from. Occasionally you will receive messages from postmaster accounts that will have no MAIL FROM address and will simply look like this: <>. These are known as null senders.
6.Your server will then respond with another OK command telling the remote server to continue.
7.The remote server will then send one or more RCPT TO commands telling your server who the message is intended to be delivered to. At this point Alligate will attempt to verify whether or not the intended recipient is legitimate.
8.After the remote server has identified all the intended recipients, it will request that it be allowed to send DATA. This is the actual message that will be delivered to the intended recipient.
9.Your server will respond giving the remote server instructions how to send the DATA portion of the message.
10.The remote server will then send the actual message.
11.Your server will acknowledge when the message has been received and the connection will be closed.


If envelope has ADDRSPACE violations add xx points: This option will add additional points if the MAIL FROM and/or RCPT TO addresses are improperly formatted. This is a very good indicator that the message is likely to be spam.


If sender has sent to bad recipients add xx points for each bad recipient: Spammers will frequently attempt to send a message to multiple recipients. Some of these recipients may be valid and some may not. Generally if a message comes in and it had several bad recipients it is most likely spam. This option will add additional points for each invalid recipient requested.


If envelope contains more then 1 RSET command add xx points for each additional RSET: RSET is the command format meaning "reset". This basically tells Alligate or any mail server to disregard previous sender and recipient information and start over during the same transaction. It is not unusual to see a remote server request a RSET one time during the transaction. It is more unusual however to see the sender request this more than once. Spammers may attempt to request a reset multiple times during the transaction. You can add penalties for each additional request for a reset.


If SMTP commands contain lower case or mixed case characters add: When the remote server sends commands to your Alligate server, the standard format is to send them in all upper case. Mixed case commands or all lower case commands usually indicate the message is from a spammer.


If HELO command fails the HELO test add xx points: When the remote server sends the HELO command identifying itself, a test is run to identify patterns in the HELO command that could indicate the messages coming from a spammer or a zombie infected computer. The HELO test can serve several purposes. It can flag the sender for tarpitting, invoke greylisting, as well as add penalty points here in the envelope scanning section.  The actual a low test is a regular expression and is defined under the greylisting options. For more information on the HELO test click here.


If HELO command is an IP address or an all numeric address add xx points: According to the rules, known as RFC's, the HELO command must refer to a fully qualified domain name (FQDN). IP addresses are not permitted, nor are all numeric addresses. This is an excellent indicator that the message is coming from a spammer.


If HELO command is not an FQDN add xx points: According to the rules, known as RFC's, the HELO command must refer to a fully qualified domain name (FQDN). As many spammers will simply use a fake name, or in some cases the name of their computer, this is an excellent indicator that the message is spam.


If the REVDNS and HELO address similarity is less than xx percent add xx points: Ideally, the REVDNS and HELO should be the same. If it were required it would be relatively easy to identify pieces spammers when these two values are not the same. Unfortunately in the real world these names are frequently not the same however in many cases they are similar. What this test does is to test the similarity of the REVDNS and HELO values. We have found through testing that the similarity of less than 40% is a good level to add penalty points at. Anything higher than 40% should probably not be penalized however anything under 40% is more suspicious.


If MAIL FROM is a NULL SENDER add xx points: Messages from NULL SENDERS are fairly common as almost all bounce messages returned from postmaster accounts indicating an unsuccessful delivery attempt will come from NULL SENDER addresses. Regular mail however should never come from a NULL SENDER address. This is not an exceptionally good indicator of spam,  however most legitimate messages coming from NULL SENDERS will not fail any of the other tests because they are usually properly formatted. As such it does no harm to add a small penalty value of 5 or 10 points because it will not affect the the deliverability a legitimate message and may help catch additional spam messages.


If MAIL FROM has no MX record add xx points: The domain name of the MAIL FROM sender is checked to see if it has an MX record. If it does not, xx points will be assessed. The A record is not checked. RFCs specify that an MX record is not absolutely required, and that if a domain is missing an MX record, the A record should be used. This test is provided on the assumption that properly configured email servers should have an MX record for hosted domains.


If not an MXRate Good Sender add xx points: If the results of the MXRate lookup for the message indicates the sender is not a known good sender, xx points will be assessed.


Related topics: HELO Test, REVDNS