1 files changed, 124 insertions, 0 deletions
diff --git a/doc/Old/PROPOSAL.mav b/doc/Old/PROPOSAL.mav
new file mode 100644
index 0000000..4e10d8a
--- /dev/null
+++ b/doc/Old/PROPOSAL.mav
@@ -0,0 +1,124 @@
+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.
+
+
+
+