Summary:

In the new era of addressing the spam problem,  new methods called LMAP (Lightweight Mail Authentication Protocol) are  available which augment SMTP to validate the sender machine of the email.  

The LMAP analysis performed in this technical review illustrates how dynamic RCPT validation at the SMTP level,  can help better define the LMAP requirements and minimize overhead issues.  In addition, it illustrates how LMAP offers 100% reliable local domain spoof protection, and how LMAP is only required when we are dealing with final destination local mail transactions.  

Background:

The biggest problem being addressed in the SMTP mail  industry is the anonymous access exploitation by spoofing spammers.  Since the classical SMTP system have "weak" or "relaxed" enforcement specifications, over 80% of all spammers have exploited the SMTP protocol due to its lack of enforcement policies to a tune of 8-9 billion dollar industry cost.

New anti-spam technologies or methods, such as LMAP augment SMTP  by providing functional guidelines in establishing an association between the sender's machine IP address and SMTP envelope domains provided by the sender.   

The following IP/Domain association assertions are made:

• LMAP = IP :: HELO domain
• LMAP = IP :: MAIL FROM domain

These LMAP associations is established by adding a domain DNS TXT record defining a domain mail policy describing which machines are authorized by the domain as authorized send mail machines.

Note: It should be noted LMAP is not a specific "how to" specification but a methodology.   Specific LMAP implementations have been developed, such as SPF, DMP, RMX, CID  and others based on the LMAP methodology of creating a IP :: DOMAIN associations using DNS TXT records.  It must be understood that LMAP does not validate the sender (MAIL FROM) email address but rather the sender machine IP address associated with the domain in the email address and/or HELO domain provided by the client.  How this is done depends on the specific LMAP proposal.

LMAP Analysis:

The purpose of this analysis is to determine the following:

• Show all the possible Envelope states,
• Showing when is LMAP validation necessary, and
• The importance of factoring all envelope parameters to further reduced the need of LMAP.

In the tables,  the following convention is used:

The following assumptions are used:

The following Table 1.0 shows all the possible combination of states for the three (3) session parameters (envelope information) IP address, HELO domain and the MAIL FROM domain.   

In group A, the SMTP server will use traditional IP relay checking to check whether the IP is local or part of the receiver server network. Hence, group A is considered to offer "trusted" sessions and LMAP is not required in this group.  In fact,  LMAP must not be used in A3 to associate the remote FROM domain because it may result in a false negative.  The possibility is a remote relay or outbound farm.  These machines must be trusted by IP outside the whelm of a domain association using traditional IP relay tables. 

Group B

In group B, like group A, the local IP should be enough to establish the trusted session. 

However, assuming proper configuration, the HELO domain should match the local IP, otherwise,  it would be a configuration error.  Of course, an SMTP session can skip HELO domain checking, however, proper setup is assumed here for the compliant LMAP client.  If your mail software can't get this right, you should consider getting working and/or LMAP compliant mail software to make sure it is playing but the 'new rules."   If it can't get the HELO domain right, how can it be expected to work when it connects to a remote system?

Group C

In group C, all fail because the HELO domain is spoofed with an remote IP address.    In a "legitimate" scenario, it is possible that the client is badly configured and is not using the correct domain or it can be a MUA not using a FQDN..  However, regardless on how broken the client software is or whether its a MUA, under no circumstance should it be using your local domain, hence it is a 100% trusted fail situation.  

In addition, in group C, LMAP may or may not be necessary.  It is possible the SMTP server can easily perform a low overhead check for HELO domain spoofing without going to DNS simply by checking its local domain list.  In fact, if LMAP is used on C9 to check for the FROM domain first, it is possible for a spoofing LMAP client to provide a false positive.

Group D

In group D, LMAP is in full throttle. The LMAP result is dependent on the association of the remote IP and either/both of the remote HELO or MAIL FROM domains.

Table 1.0 shows LMAP could be used in 6 of  total 12 possible states . However, 3 of these 6 states are failed states due to local domain spoofing.  LMAP can be used to return these result, however, it is probably unnecessary overhead to check for local domain spoofing. This can best be shown in  in next Table 2.0  which  illustrates how group C and D can be expanded into 12 new envelope states when dynamic RCPT validation is considered prior using LMAP.

Group CL

In group CL,  local RCPT is considered.   As you can see, LMAP is only required for final destinations (RCPT is local) transactions.   If RCPT is remote, then authentication is required otherwise we have an open relay situation.

Group CR and DR

In groups CR and DR, there is no need to perform LMAP because the session is presumed anonymous, therefore only final destination mail is allowed.  In this is not the case, then we have an open relay. For remote RCPT distribution,  NULL return paths can not be used and authentication is required. 

Please note that in practice, many systems can be configured not to perform RCPT validation and will have a post or delayed RCPT delayed situation.  Systems such as slip gateways may fall in these category.  These systems are problematic in the fight against spam-viruses because they increase the possibility of bounce requirements.

Group DL

In group DL, LMAP is in full throttle and used only for final destination mail.   Although,  LMAP may be used in group CL to address the local domain spoofing, a system implementation may consider using a lower overhead method that does not require DNS.

Summary

Table 1.0 shows LMAP is only required when the IP is remote and the remote client is not spoofing the domains.

Table 2.0 shows LMAP is only required when we are dealing with final destination local mail transactions.  

Table 2.0 shows LMAP when dynamic RCPT validation is performed at the SMTP level,   LMAP overhead issues can be drastically reduced to a minimum necessity usage.  A total of 18 possible states can be reduced to 6 states where LMAP is only necessary.