diff options
author | Jannis Hoffmann <jannis@fehcom.de> | 2024-07-03 15:48:04 +0200 |
---|---|---|
committer | Jannis Hoffmann <jannis@fehcom.de> | 2024-07-03 15:48:04 +0200 |
commit | 89b7b67a13ebb7965cc7f13ad0595e2194a2d34c (patch) | |
tree | 25efd77a90ae87236e6730d8ea3846bbe0fd126f /doc/Old/PROPOSAL.mav |
add sqmail-4.2.29asqmail-4.2
Diffstat (limited to 'doc/Old/PROPOSAL.mav')
-rw-r--r-- | doc/Old/PROPOSAL.mav | 124 |
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. + + + + |