Mail From: Address Verification, MAV-2005
Copyright 2005

Erwin Hoffmann, feh@fehcom.de


1. Scope

SMTP is a protocol with very few commands. Only 'Helo'/'Ehlo', 
'Mail From:', 'Rcpt To:', 'Data' and 'Quit' are necessary 
to initiate, perform, and terminate a SMTP session. Here, 
the 'Helo'/'Ehlo' provides information about the sending MTA, 
which in current MTA implementations is not always required, 
while the 'Mail From:' and 'Rcpt To:' is used to build the 
SMTP envelope.

Apart from the 'Rcpt To:' information, the recipient MTA can 
not verify any other information. Both the 'Helo'/'Ehlo' and the
'Mail From:' is often forged or faked, thus not reliable in
particular in case of Spam emails.

The proposed 'Mail From:' Address Verification (MAV) implements
a scheme, how the associated information can be verified at the
responsible sending email gateway and perhaps can be promoted to the 
recipient MTA. In this scheme, the provided 'Mail From:' information 
is authoritive.  


2. Responsible Email Gateway

MAV takes place at the responsible email gateway. The responsible 
email gateway acts as relaying gateway for those networks and users 
solely transmitting (and receiving) SMTP emails through this gateway.

Though SMTP is a Host-to-Host protocol, SMTP Authentication yields
a User-to-Host mechanism. Thus, the responsible gateway has to take
care about the following senders:

(1) networks/hosts, identified by there IP or FQDN (available by 
    DNS lookup),
(2) users/senders, identified by means of SMTP Authentication or other
    mechanisms like POP-before-SMTP.

With MAV, it is possible to check and verify the integrity of the 
provided 'Mail From:' envelope address 

(a) domain-based, by means of the provided IP-address/FQDN of the 
    sending MTA,
(b) user-based, in case SMTP Authentication (or another user-based 
    method) is in place.

Typically in the first case, only the domain-part of the 'Mail From:'
SMTP envelope address can be verified (the part right from the '@', 
i.e. user@domain), while in the second case the full qualified 
address may be subject of the MAV, providing a mapping between the 
userid for SMTP Authentication and the chosen 'Mail From:' address.


3. Comparision with other verification schemes

Today, it is common to reject emails in case it fails certain 
authorization/verification criteria: 

(1) Testing the IP address of the sending MTA against Realtime Blacklists 
    (RBL) available on the Internet,
(2) verification of the domain-part of the provided 'Mail From:' address 
    doing a DNS lookup (reverse Return-Path must exist) or SMTP lookups,
(3) employing the Sender Policy Framework (SPF), thus checking whether
    the domain-part of the 'Mail From:' address is authoritive with
    respect to the sending MTA,
(4) verifying (locally) the existance of the forseen recipient ('Rcpt To:'),
(5) checking the contents of the email by means of baysean approaches
    or by checksums.

In any case, the receiving MTA is responsible to realize more or less 
complex checks to accept or reject emails applying those means.

Opposite to this, MAV adds a qualification to the responsible email 
gateway; comparable with SMTP Authentication. 


4. MAV enabled responsibe email gateway

The tasks of a MAV enabled responsibe gateway are the following:

(1) The gateway is knowledgeable about those emails to be allowed
    for unrestricted relaying. Typically this is facilitated due
    to the knowledge to the sender's IP/FQDN or by means of SMTP
    Authentication, Pop-before-SMTP, or any other.
(2) The gateway has access to a list which maps the sender 
    qualification information with a list of allowed domains as
    part of the 'Mail From:' address or particular 'Mail From:'
    addresses. 
(3) Emails failing this test will be rejected initially during
    the SMTP session.
(4) Emails passing the test are allowed to relay.
(5) The gateway adds the keyword 'ESMTPM' into the receiving
    email header. Thus, the next hop email system is able to
    verify the authoritive usage of the 'Mail From:' address.


5. Dependencies on other email RFCs

- RFC 2821: Service extensions: None.
- RFC 1893: Enhanced Mail System Status Codes: None.
- RFC 3848: ESMTP and LMTP Transmission Types Registration: Yes.
  MAV adds a new keyword 'ESMTPM' which complements the keywords
  'ESMTPA' and 'ESMTPS'; thus in addition the combinations 
  'ESMTPAM', 'ESMTPSM', and 'ESMTPSAM' are valid.


6. Security considerations

Information in the email header is easy to forge or manipulate.


7. History

Parts of the MAV approach was first introduced in the SPAMCONTROL 
patch for Qmail 1.03, based on ideas initiated by the LDI, Mainz, Germany.