Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!shadooby!samsung!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!OAC.UCLA.EDU!CSYSMAS
From: CSYSMAS@OAC.UCLA.EDU (Michael Stein)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Host requirements and SMTP
Message-ID: <9001060622.AA28788@ucbvax.Berkeley.EDU>
Date: 5 Jan 90 17:57:00 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 37

> Section 5.2.5
> The discussion about resolution of the HELO parameter is not that
> essential anyway, to my mind what is more important is that you can
> discover where the SMTP connection is coming from.  I.e. if you
> can't resolve the IP address back to a domain name then you
> probably should not accept the mail because

HRRFC 5.2.5 says "However, the receiver MUST NOT refuse to accept
a message, even if the sender's HELO command fails verification."

I can't see how that could be clearer -- LET THE MAIL GO THROUGH.

I also remember (from one of the domain RFCs?) that the prefered
way to "check" the HELO name is to do a forward DNS lookup on the
supplied name and see if one of the A records contains the IP
address for this SMTP connection.  This is in preference to the
reverse lookup (IP address to domain name using IN-ADDR.ARPA).

In my opinion the forward lookup sounds much more reliable than
the reverse, however they both sound like they take too long for
a "high performance SMTP implementation".

>        a) you don't know who is sending you the message really, so
>        your chances of getting it back are limited if things blow up.
>        b) You don't know who is really sending the message - from a
>        security point of view. IP addresses can be forged but this is
>        better than nothing - certainly better than implicitly
>        believing the HELO.
> Therefore I would argue all the authentication should have been done
> before it gets to the HELO stage. A future HR should perhaps note that
> you should attempt to discover where the message is coming from.

There isn't any way to do this in SMTP.  All you have is the
domain name (claimed) and the IP address (also claimed).  You
don't know who sent the "bits" or if they have been modified.  If
you really need authentication see the RFCs on privacy
enhancements for electronic mail (RFC1113-1115).