Colm MacCarthaigh wrote:
>
..[snip]...
>
> > I.e. I agree those techniqes are not possible without
> > delaying reject responses, but I will also say that those techniques
> > are far less useful than their proponents claim them to be and what
> > little benefit they might have is far outweighed by the ultimate
> > "damage" they do to SMTP.
>
> SMTP is an inherently illconstructed, insecure, outdated mess. The point
> at which we have more to worry about the damage we cause it than the
> damage it causes us has long ago since passed. The world is full of
> misconfigured exchange boxes, with which we must interoperate, that
> arn't going away; the war is lost.
Here is were I disagree. SMTP is no more 'insecure' by nature than
HTTP, POP, IMAP etc. The reason most people say that SMTP is insecure
is because 'you cannot verify the sender'. That is true, and it is
also not true.
It is true that without encryption of the entire message at compose
time, there is no way to 'verify' the sender. In other words,
"header FROM:<>" and SMTP "MAIL FROM:" will never be a valid way to
'verify' that 'Bob' really did send that message.
It is not true that we cannot 'verify' the source of the SMTP
transaction however. This is not the same thing as verifying that a
particular sender actually sent a particular message. This is the
'verification' of the connecting machine. How you verify the source
of the transaction is with DNS. DNS is an integral part of the
SMTP transaction. The two go hand-in-hand when comes to the SMTP
transaction, and verification of the source 'client'. All of the
relevant RFC's (82[12], 282[12], 112[23], and others) very specifically
state or imply that a connecting host is to identify itself with its
proper 'hostname+domain' (FQDN), or use the IP Literal to identify
themselves. As per the RFC's a proper FQDN is defined as a DNS A
record that matches the IP address, and for each DNS A record,
there is a matcing DNS PTR record, AND, all information returned has
to be a 'routable' address from the server connected to, so if you
connect to a server on a private network, it is OK to have the DNS
information returned be on a private network that is routable from the
server, however it is not OK to have DNS return private, local, or
any other form of unroutable address when connecting to a server on the
Public Internet, Ebay is a good example of this type of misconfiguration.
Getting back to the HELO/EHLO... So in the case of say a dynamically
assigned address from your ISP, you would not HELO/EHLO with
'host.mypersonaldomain' but instead, a string that matches the DNS PTR,
and a DNS A record (i.e. adsl-1.2.3.4.myisp), in the absence of a
valid DNS A record, you just use the IP in the form of [xxx.xxx.xxx.xxx]
for SMTP transactions. Even when using the IP Literal, there really
should be a valid DNS PTR record for the address. Proper DNS information
is the only way to very the 'validity' of a client connection. The only
reason that we continue to see such broken DNS informaiton in relation
to HELO/EHLO is because too many sites did not care to enforce what
all the RFC's already say is the only proper and good pratice when
initiating an SMTP transaction.
The majority of the work that people are now trying to do in fighting
SPAM is going in the wrong direction in this respect. We do not need
SPF to 'verify' a connection, and SPF will never be able to 'verify'
the sender of the message, again, that is what message encryption is
for (along with a few other benifits), to verify a single message.
However, message encryption does not verify the connecting machine,
that is what DNS is for. Also, if you go and read the current
information on the main SPF site, they have all of this in the
'What policies besides SPF should I put in my MTA?' section of
thier FAQ (
http://spf.pobox.com/faq.html). Like it or not, what
myself, Greg, and others have been trying to say is just that.
Utilize proper DNS, enofrce the use of proper DNS, and THEN let us
see what other things need to be enforced, such as properly formatted
"SMTP FROM:" strings, that also have proper DNS information.
The SMTP related RFC's are not as 'insecure' as many people believe, not
when you actually read them, AND take into consideration supporting
RFC's on DNS, Host requirments for the Public Internet, etc.
The first step in 'fighting SPAM' is to first start with enforcing
the current standards, perhaps with a touch of re-wording, or
stronger language (change SHOULDs to MUSTs for example) before we
start complicating things with 'fixes' that are more complicated,
unnecessary, and at times, out right broken.
SMTP is a wonderfull protocol just for the reason that it is
'open'. It is easy to implement, and implement properly I might add,
easy to understand, and easy to use. The same applies to HTTP, FTP,
telnet, and many other protocols that have been in use for very long
periods of time. There are reasons that protocols that are complicated
to implement and understand do not stay in use for very long, and/or
do not become widely utilized outside of niche market segments.
>
..[snip]...
>
To reduce 'noise' I did snip the reset of the message, as the
response above covers most of what was said in those parts of the
message. Apologies to those that may need to go lookup the rest
of that message in the archives.
--
--EAL--
