1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
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.
|
