j.onions@computer-science.nottingham.ac.UK (Julian Onions) (01/05/90)
I have just been upgrading an SMTP server/client to attempt to conform to the HOST REQUIREMENTS RFC. Most of the stuff is fairly sensible and lays down good practice. I have some comments on this generally though and wondered if anyone else has attempted to conform to this specification as yet? Anyway, maybe someone can answer these questions or shed some light... Section 5.2.3 This seems nonsensical, saying essentially you MUST implement VRFY and SHOULD implement the EXPN commands, but both of these MAY be disabled. So to conform I can simply implement both these by replying with 252 Cannot VRFY User and 550 Access Denied to you Just changing these from 500 Unknown of unimplemented command seems pretty worthless What benefit do you gain from making VRFY a MUST when its quite acceptable to always answer "can't"? Section 5.2.5 A question/comment - is HELO really required? I know of one implementation that doesn't send HELO messages (MH) and the HR makes it clear that you should mostly ignore the HELO stuff anyway. 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 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. Section 5.2.8 Various things should be pushed into the Received line it notes, but I don't see how this can be done. Firstly the from field should contain both a source host and a domain literal of the IP address. Good - but how, the grammer gives exactly one FROM per received line in rfc-822 in the format from domain similarly there is only one FOR address allowed - perhaps a new grammer should have been given here. Otherwise things like the RFC-822 -> X.400 gateways that try and preserve trace are going to have problems parsing these lines. Section 5.2.14 New date format is good - but is this going to break existing systems and implementations I wonder? Section 5.2.17 Urgghhhhh! This is awful. Making this a MUST is horrible. Domain literals should be stamped out. Parsing a domain literal is ok, getting the semantics right is yucky in the extreme, it should at the maximum have been a MAY. Next thing we'll need to recognise our own ethernet addresses in mail messages. So to be conformant you HAVE to be able to discover all your current IP addresses and to match on them. Does this really have to be a MUST? How many current systems can accept this syntax? I think this will be my biggest stumbling block to conformance. My ideal text for this section would have been "Domain literals are not intended for address use, an Implementation MAY make use of them for routing, and SHOULD NOT fail outright if one is detected. Instead if domain literals are not supported, the affected addresses may be returned with a failure notice. Domain literals are only intended for tracing purposes." Domain literals together with source routing should be dropped. Section 5.5.3 This says if you have a source route as the originator of the message then an error message SHOULD throw away the route. So if somewhere on the Internet I get an address allegedly from <Internet-Host:user@hidden-host> where hidden-host is not directly contactable I must throw away the Internet-host route part when sending an error. The most likely reason for having a route in the originator is because the hidden host does not yet have an entry in the DNS or an MX record for its domain, so in that case there is no way to get back without the route. I think these are the main things that hit me when trying to conform to the HR. I would welcome comments. Julian.
craig@NNSC.NSF.NET (Craig Partridge) (01/05/90)
Julian:
Let me see if I can answer some of your questions.
> Section 5.2.3
> This seems nonsensical, saying essentially you MUST implement
> VRFY and SHOULD implement the EXPN commands, but both of these MAY be
> disabled.
> So to conform I can simply implement both these by replying with
> 252 Cannot VRFY User
> and
> 550 Access Denied to you
> Just changing these from
> 500 Unknown of unimplemented command
> seems pretty worthless
> What benefit do you gain from making VRFY a MUST when its quite
> acceptable to always answer "can't"?
Let me just clarify the text here. It says MUST implement and MAY
provide the facility to allow users to turn them off.
The reason was that, in general, EXPN and VRFY are useful tools for
tracking problems in mail-lists expansions. However, EXPN and VRFY
are also viewed by some members of the community as a violation of
privacy (Why should someone be able to find out whether I'm on mailing
list X? Or why should someone be able to find out who is on my
personal mail-lists?). Furthermore, both commands are minor security risks --
since mailbox names often are the same as account names. So we state
that it is reasonable for users to ask for mail software in which they
can turn off EXPN and VRFY.
> Section 5.2.5
I don't know what to say here. HELO is part of the protocol, so yes
you ought to do it. That said, yes, it doesn't do much.
> Section 5.2.8
> Various things should be pushed into the Received line it notes, but I
> don't see how this can be done. Firstly the from field should contain
> both a source host and a domain literal of the IP address. Good - but
> how, the grammer gives exactly one FROM per received line in rfc-822
> in the format
> from domain
> similarly there is only one FOR address allowed - perhaps a new grammer
> should have been given here. Otherwise things like the RFC-822 ->
> X.400 gateways that try and preserve trace are going to have problems
> parsing these lines.
I believe you are right and we goofed here.
> Section 5.2.17
> Urgghhhhh! This is awful. Making this a MUST is horrible. Domain
> literals should be stamped out. Parsing a domain literal is ok,
> getting the semantics right is yucky in the extreme, it should at the
> maximum have been a MAY.
> <some text deleted...>
>
> My ideal text for this section would have been "Domain literals are not
> intended for address use, an Implementation MAY make use of them for
> routing, and SHOULD NOT fail outright if one is detected.
> <more text deleted...>
Gee -- that's what we tried to do, only a bit more forcefully. Domain
literals may show up, your mailer must not barf on them, and if the
domain literal = your host, your mailer ought to accept it. In other
words, God help us, should you get a domain literal, do the minimum
rational thing -- don't fail, and swallow it if it is for you.
> Section 5.5.3
> This says if you have a source route as the originator of the message
> then an error message SHOULD throw away the route.
> So if somewhere on the Internet I get an address allegedly from
> <Internet-Host:user@hidden-host>
> where hidden-host is not directly contactable I must throw away the
> Internet-host route part when sending an error. The most likely reason
> for having a route in the originator is because the hidden host does
> not yet have an entry in the DNS or an MX record for its domain, so
> in that case there is no way to get back without the route.
This isn't what were saying. What we were saying is there is good
reason in the envelope to track how the mail has proceeded -- the
typical way to do this is source routes (@A,@B:user@C) where user@C
is the originating system. Now there's no point in replying via
all the intermediate hops -- and now that source routes are
discouraged, it may not even fly. So just strip down to user@C.
In the case you cite, I'd argue the gateway should have sent stuff
out as user%hidden@host, which would then become @A,@B:user%hidden@host,
and you'd reply to user%hidden@host.
Craigj.onions@computer-science.nottingham.ac.UK (Julian Onions) (01/05/90)
Craig, thanks for the reply - it clears up most of the points. > > Section> 5.2.17 > > Urgghhhhh! This is awful. Making this a MUST is horrible. [I waffle on].. > Gee -- that's what we tried to do, only a bit more forcefully. Domain > literals may show up, your mailer must not barf on them, and if the > domain literal = your host, your mailer ought to accept it. In other > words, God help us, should you get a domain literal, do the minimum > rational thing -- don't fail, and swallow it if it is for you. Having to deal with them at all is the problem. The bit that grates on me is half way through parsing the address you have to suddenly fly off and discover what all your current IP numbers are. In an otherwise faily portable bit of software such as an address parser, suddenly having to dig down into the depths of the currently configured interfaces is ugly. IP addresses have no place at the mail address parsing level. I can now sort of see the rationale behind them. From reading the HR spec, I sort of imagined (rightly or wrongly) that the debate went something like: "Look, its a really useful debugging technique to send direct to IP addresses, so lets force everyone to handle d-lits and debugging becomes a lot easier. We can even source route using IP addresses then if required." I would still prefer that you MUST be able to parse the construct but that you MAY ignore them and can bounce a message if it requires understanding them. I think the reason for my unease is that the HR are pretty strong on discouraging source routing. The d-lit section doesn't say they are discouraged, just that you must be able to parse them and recognise your own - which sounds more like encouragement of their use. Inserting your text above would really show what was meant! Julian.
davecb@yunexus.UUCP (David Collier-Brown) (01/06/90)
j.onions@computer-science.nottingham.ac.UK (Julian Onions) writes: >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. Well, one of them comes from my CP/M-80 machine via a terminal server... If I wanted to pay thge long distance costs, they could come from "dial smtp" on a Multics box, etc, etc. And if you do happen to be using IP, your name may not be registered yet. > 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. I have to agree with this: without a previous agreement at the human level the mailer using smtp won't know to queue the mail for me and will simply refuse it. > 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. And we clearly need an authentication mechanism, for which the HELO construct is the normal hook (ie, its included even though not strictly necessary: guess jon was thinking ahead (:-)) --dave -- David Collier-Brown, | davecb@yunexus, ...!yunexus!davecb or 72 Abitibi Ave., | {toronto area...}lethe!dave Willowdale, Ontario, | Joyce C-B: CANADA. 416-223-8968 | He's so smart he's dumb.
CSYSMAS@OAC.UCLA.EDU (Michael Stein) (01/06/90)
> 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).
barns@GATEWAY.MITRE.ORG (01/06/90)
If I don't answer this, Rayan Zachariassen probably will, and I like my
version better... (Rayan is a good sort really, but we did have a lot of
interesting or tedious discussions during the editing of this part of
HR.) Most of these issues involve unprovable propositions - I for one will
concede that in advance. Herewith my recollections and comments:
Section 5.2.3
So to conform I can simply implement both these by replying with
252 Cannot VRFY User
and
550 Access Denied to you
Just changing these from
500 Unknown of unimplemented command
seems pretty worthless
What benefit do you gain from making VRFY a MUST when its quite
acceptable to always answer "can't"?
A trivial answer to this is, "if you choose to implement something in
the stupidest way you shouldn't be surprised if the product is worthless."
The hoped-for result here was: Almost all SMTP implementations ought to
be capable of doing real EXPN and VRFY service for some set of cases.
Many will find it unduly costly or infeasible for some other set of cases.
Finally, there may be security or policy reasons why it is desired not
to make certain names visible in this way. This might be all of the names
at a site or only a few. So the intent here is to tell the developer to
produce the code with the ability to do the functions in the cases where
it is technically reasonable, and let the user/purchaser decide what
additional restrictions to apply.
Section 5.2.5
A question/comment - is HELO really required? [...]
As an abstract question, this has no provable answer. As a matter of
protocol definition, it is required. People's sentiments vary, but
the implication of what was ultimately specified is something like this:
The HELO command is there so the server will have an identity assertion
about the client process. It is not intended to be a real
authentication procedure. Strong authentication, or even "halfway"
authentication, takes more work and not everyone thinks the effort is
justified. Some people (including me) feel that receipt of mail (in
the normal workaday world - not talking about multilevel secure
systems, electronic funds transfer or other specific needs) should not
be conditioned on any type of authentication - you take anything that
shows up at the door, and then assess its worth after you read it if
you still care.
Converting the IP address back to a host name requires sending more
traffic and doing more overhead work. Opinions vary on whether it is
worth it. There's also the practical problem that the IP-address
part of the domain tree seems to have more screwups in it. HR dodges
all of these concerns by saying "invert the IP address if you wish but
don't throw away the mail because of anything that happens - instead
tell the recipient and let the recipient decide".
Section 5.2.8
Various things should be pushed into the Received line it notes, but I
don't see how this can be done. [...]
Most of the miscellaneous things were envisioned as syntactic comments,
which are permitted by the RFC822 syntax rules. For example:
Received: from ALLEGED.DOMAIN ([11.22.33.44]) by MY.DOMAIN [etc.]
The question of the syntax of the FOR was brought up by Rayan
Zachariassen during the editing (as I am sure we will be justly
reminded). I suppose there was some feeling that in view of the
attitude expressed in the second chunk of DISCUSSION in section 5.2.8
("Received: lines are primarily intended for humans...") that it wasn't
too important to make this concrete. Syntaxes discussed for the
contents of the FOR included 1#mailbox, 1#route-addr, and 1#(addr-spec
/ route-addr) with the last given being the last one discussed
(according to my files). I think that 1#mailbox covers the other
cases, so if I wanted to parse it today, I'd use 1#mailbox until it
broke.
Section 5.2.14
New date format is good - but is this going to break existing systems
and implementations I wonder?
RFC733, the predecessor of 822, allowed four digit years. I thought it
was strange that it was taken out in 822, but in those days I wasn't
involved in the writing of these things. I know there was a feeling
that 733 allowed an excessive number of date formats for no particular
reason. I suppose "they" overreacted slightly when updating it (in
822). I hope and believe we are converging on sanity at least in this
one area.
Section 5.2.17
Urgghhhhh! This is awful. Making this a MUST is horrible. Domain
literals should be stamped out. Parsing a domain literal is ok,
getting the semantics right is yucky in the extreme, it should at the
maximum have been a MAY [...]
Having had misadventures with DNS, I'm a believer in this provision as
an escape mechanism when the DNS misbehaves and you really need to talk
to someone. Given this rule, hosts A and B can manage to talk despite
any DNS screwups on C. I don't really understand why this is hard.
True, it's one more thing to code. I don't see huge semantic problems
at least when the domain literal is a dotted-decimal IP address, which
is the only case actually addressed in HR (which is about *Internet*
hosts). It is slightly ugly that one ought to cope with [11.22.33.44]
and [011.022.033.044] being equivalent, but this can be handled by
converting to the 32-bit number. The code may be a little disgusting,
but it shouldn't have to be lovingly optimized since it shouldn't be
used very often. If you were thinking that you have to canonicalize it
(rewrite the header or some such), you don't - read section 5.2.2
closely; it legitimizes allowing domain literals to pass unaltered.
Section 5.5.3
This says if you have a source route as the originator of the message
then an error message SHOULD throw away the route. [...]
The philosophy arrived at by a combination of discussion and decree was
something like: We wish explicit source routes within the Internet had
never been defined. Since this unfortunate decision was made and many
people implemented it, we will put in enough requirements so that mail
items using them won't be rejected by anyone as illegal, but we will do
everything possible to keep any more such mail items from being
created.
Note that this doesn't refer to "%-hack" or the like. The
left-hand-side is a local matter relative to the specified
right-hand-side. (This is just about the only aspect of this touchy
topic on which I tend to wax religious.)
So, the "blessed" answer to the scenario you describe is for the
original sender to use %-hacks or the like on the LHS with the
cooperation of some Internet-registered domain, or perhaps use domain
literals for a very short time, but eventually get MX's or full DNS
connectivity.
Incidentally, Jon Postel "decreed" years ago that it was always
intended that all domain names appearing on the Internet, including
those in source routes, are supposed to be Internet-registered names.
Under that dictum, the case you describe as most common should never
have been allowed to occur, with or without the HR RFCs. (As all
sensible people know, the real world doesn't always follow the rules.
The point is just that any variations were unsanctioned by the Powers
That Be.)
The topic of explicit mail source routes is exceedingly controversial
and generated about 20-25% of the total volume of discussion that led
to these RFCs. It has been like this for years. Groan.
Bill Barnsbraden@VENERA.ISI.EDU (01/06/90)
Julian,
Thanks for your comments.
Section 5.2.3
This seems nonsensical, saying essentially you MUST implement
VRFY and SHOULD implement the EXPN commands, but both of these MAY be
disabled.
So to conform I can simply implement both these by replying with
252 Cannot VRFY User
and
550 Access Denied to you
According to the intent of the HR WG, this would NOT satisfy the requirement
for implementation. To implement the command, your code must include the
necessary algorithms and data structures which, if enabled by a particular
site administrator, would actually perform the intended function.
Note that the HR RFCs generally specify what must be present in the code,
regardless of how particular sites choose to configure their systems.
Section 5.2.5
A question/comment - is HELO really required? I know of one implementation
that doesn't send HELO messages (MH) and the HR makes it clear that
you should mostly ignore the HELO stuff anyway.
Except as specifically mentioned in the HR RFC, all parts of RFC-821
are required. Sending HELO is part of the SMTP protocol (see Section
3.5and all the examples of RFC-821); although the WG never discussed this
point (discussion would have been gratuitous), I think I can state with
certainty that sending HELO is required.
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
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.
The limitations of HELO validation and IP addresses for hard-core
authentication are very well known. However, there is a lot of experience
in which HELO parameters have been useful for diagnosing mail delivery
problems.
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.
The requirement in Section 5.2.8 to include the IP source address in the
Received: line is intended to do exactly that. It was felt that both
pieces of information are useful for diagnosis.
Various things should be pushed into the Received line it notes, but I
don't see how this can be done. Firstly the from field should contain
both a source host and a domain literal of the IP address. Good - but
how, the grammer gives exactly one FROM per received line in rfc-822
in the format
from domain
similarly there is only one FOR address allowed - perhaps a new grammer
should have been given here.
Some argued for this, but the WG decided that this should be left to
a future revision. Many (but not all) WG members felt that the intent of the
Received: line is to provide trace information for humans, so that a
precise syntax is not a very important. Here's a suggestion: put the domain
literal after the host domain name, with one or more blanks separating the two.
Otherwise things like the RFC-822 ->
X.400 gateways that try and preserve trace are going to have problems
parsing these lines.
Gateways are specifically prohibited from modifying modifying Received:
lines! (Section 5.3.7 (B)). So they don't need to, and should not try,
to parse these lines.
Section 5.2.14
New date format is good - but is this going to break existing systems
and implementations I wonder?
The WG felt that we have a choice of breaking things gradually over the
next 10 years or all at once on 12/31/99, and preferred the former. One
could argue that, I suppose.
Section 5.2.17
Urgghhhhh! This is awful. Making this a MUST is horrible. Domain
literals should be stamped out.
The WG felt that domain literals are an important escape mechanism for
users when the DNS is screwed up: a user-helpful feature. Implementation does
not seem to me to be that big a deal compared with the overall 821/822
implementation job.
Again, we appreciate your comments, and they will be saved for the lucky
people who get to revise the HR RFC.
Bob Bradenmrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) (01/06/90)
In article <24861.631484091@cs.nott.ac.uk> j.onions@computer-science.nottingham.ac.UK (Julian Onions) writes: >Section 5.2.17 >Urgghhhhh! This is awful. Making this a MUST is horrible. Domain >literals should be stamped out. Parsing a domain literal is ok, >getting the semantics right is yucky in the extreme, it should at the >maximum have been a MAY. Next thing we'll need to recognise our own >ethernet addresses in mail messages. So to be conformant you HAVE to >be able to discover all your current IP addresses and to match on >them. Does this really have to be a MUST? How many current systems can >accept this syntax? I think this will be my biggest stumbling block to >conformance. You must recognize a domain literal that refers to yourself. There are reasons for using domain literals, including being able to get through to a working IP address that can't (for some reason) be accessed by a name. There are any number of reasons for this including DNS failure, inconsistent DNS information, or no DNS!!! There have been abundant problems because of stupid stupid mailers that fail to recognize one of their own IP addresses in a domain literal and eventually get into a loop or bounce the message. A few years ago, the TOPS-20 mailer was stuck with a DNS resolver which did not offer reasonable canonicalization or MX access. The only way it could get the canonical form of a name (as opposed to a possible non-fully-qualified name or CNAME) was to look up the IN-ADDR.ARPA PTR record for that IP address. It couldn't MX at all. The problem is that many hosts did not have IN-ADDR records or the information was inconsistent. If it could not get an IN-ADDR record, it substituted the domain literal rather than inflict a name that someone else may not recognize on the rest of the world. Today, TOPS-20 systems have a reasonable resolver to talk to that supports DNS-level canonicalization as well as MX. So these systems tend to use domain literals a lot less. However, they still support domain literals as an escape mechanism. Consider the modern case. I try to mail to you. However, the DNS server for you is down and has been down for several days. I know your IP address, I can telnet to you, but I can't mail to you. Even though my mailer knows that your address is "unresolvable" instead of "bad" and keeps on trying for a few days, eventually it returns the message as undeliverable. Well, damnit, I should be able to mail to you using your IP address. Well, I can. But if you have a stupid mailer that sees the message as a "mail to IP address a.b.c.d" and passes it on without realizing that you *ARE* a.b.c.d the message is in a loop. The correct way to handle domain literals is to consider both a host name and a domain literal as a single atomic entity with a name property and an IP address property. When dealing with mailbox at this atomic entity, you have to check to see if this entity is yourself. So, the name property, when canonicalized, should be the same as your local name. You simply have to implement the concept of "canonicalizing" for a domain literal. That is, finding out, if possible, what host the domain literal refers to and substituting that name. Presumably, if the domain literal refers to one of your own IP addresses you should be able to substitute your local name!!!!!!!! Really, this is pretty important. Too many mailers implement this wrong. _____ ____ ---+--- /-\ Mark Crispin Atheist & Proud _|_|_ _|_ || ___|__ / / 6158 Lariat Loop NE R90/6 pilot |_|_|_| /|\-++- |=====| / / Bainbridge Island, WA "Gaijin! Gaijin!" --|-- | |||| |_____| / \ USA 98110-2098 "Gaijin ha doko ka?" /|\ | |/\| _______ / \ +1 (206) 842-2385 "Niichan ha gaijin." / | \ | |__| / \ / \ mrc@CAC.Washington.EDU "Chigau. Gaijin ja nai. kisha no kisha ga kisha de kisha-shita Omae ha gaijin darou." sumomo mo momo, momo mo momo, momo ni mo iroiro aru "Iie, boku ha nihonjin." uraniwa ni wa niwa, niwa ni wa niwa niwatori ga iru "Souka. Yappari gaijin!"
lear@turbo.bio.net (Eliot Lear) (01/06/90)
RE HR 5.2.3: The goal was to give the option to the system administrator the option of disabling these commands either altogether or for private lists, depending on that particular site's requirements (as stated in DISCUSSION). RE HR 5.2.5: I would agree that HELO has really outlived its usefulness (sendmail doesn't even require it). Were I you, I would check the connecting address and use that instead of HELO to do verifications. In either case, you need to accept the mail involved. On the client side, you would be foolish to implement code that does not issue a HELO, as there are sites out there that will barf with a protocol botch error. RE HR 5.3.3 (I presume, as there is no 5.5.3): I don't understand. In the previous line you say, ``Doamin literals together with source routing should be dropped,'' and then go on to argue the case where you want to use source routing. In either the case where you have MX records, or even if you are dealing with a site that isn't registered, source routes as defined by RFC822 are useless because all the hosts listed have to be registered. -- Eliot Lear [lear@turbo.bio.net]
brian@ucsd.Edu (Brian Kantor) (01/07/90)
HELO is of use in an environment where the underlying transport does not provide a means for identifying the peer: i.e., it's not tcp/ip. I'm told that DATAKIT is one such; clearly there are others. We've added an optional HOST command to NNTP for precisely such purposes. Occasionally I forget that some of the higher-level Internet protocols are used on other than the Internet. - Brian
sra@LCS.MIT.EDU (Rob Austein) (01/09/90)
Julian, Back when Mark Crispin and I were implementing the current interface between the TOPS-20 mailer and domain resolver, we concluded that we would be best off avoiding the IN-ADDR.ARPA portion of the DNS tree if at all possible. Informal observation convinced us that the IN-ADDR tree is, on the whole, significantly less accurate than the main portion of the DNS tree. Sad, but true. So our validation mechanism does indeed want the name from the HELO command as a starting point. It will let the mail through if the validation fails, it just makes a lot of rude comments and flags the failure in the Received: header. There are other reasons why the HELO command is useful (eg, the BSMTP protocol), but this one is rooted in a real and current Internet problem. I for one would be unhappy if the SMTP protocol didn't have the HELO command. --Rob Austein
mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) (01/09/90)
In article <9001060622.AA28788@ucbvax.Berkeley.EDU> CSYSMAS@OAC.UCLA.EDU (Michael Stein) writes: >HRRFC 5.2.5 says "However, the receiver MUST NOT refuse to accept >a message, even if the sender's HELO command fails verification." This brings up a related issue. The TOPS-20 SMTP server will reject a HELO under two circumstances: a) syntax invalidity b) the HELO claims to be the local host, but the IP address is not one of the known local IP addresses. It also requires the successful negotiation of a HELO before starting a MAIL transaction. As I read the HRRFC, this is not allowed behavior any more, but I haven't heard any complaints about this behavior either. That is, I have never heard any complaints of mail not getting through to a TOPS-20 system because the SMTP client: a) uses bogus syntax in its HELO b) claims to be the TOPS-20 system it is talking to. c) doesn't want to do a HELO before starting a transaction My question is, do we really want to outlaw behavior that isn't causing a problem? I can get rid of these behaviors; it involves the deletion of a few lines of code. I don't believe it's desirable to do so. However, I have this nightmare of someone with a truly sick SMTP client taking me to task for not obeying the HRRFC. The check for local host is a useful behavior, albeit less useful in TCP days. Basically, it catches "mirrors" (which is what HELO was put in to get rid of). Mirrors were a common problem in NCP days, but still pop up from time to time in TCP. I've seen hosts in debugging states that reflect TCP connections. My understanding of what the HRRFC was trying to outlaw was rejecting a HELO when the name was unknown, or the name didn't match; problems that generally were due to out of date host tables or DNS information. Has the HRRFC gone a bit too far in the opposite direction? _____ ____ ---+--- /-\ Mark Crispin Atheist & Proud _|_|_ _|_ || ___|__ / / 6158 Lariat Loop NE R90/6 pilot |_|_|_| /|\-++- |=====| / / Bainbridge Island, WA "Gaijin! Gaijin!" --|-- | |||| |_____| / \ USA 98110-2098 "Gaijin ha doko ka?" /|\ | |/\| _______ / \ +1 (206) 842-2385 "Niichan ha gaijin." / | \ | |__| / \ / \ mrc@CAC.Washington.EDU "Chigau. Gaijin ja nai. kisha no kisha ga kisha de kisha-shita Omae ha gaijin darou." sumomo mo momo, momo mo momo, momo ni mo iroiro aru "Iie, boku ha nihonjin." uraniwa ni wa niwa, niwa ni wa niwa niwatori ga iru "Souka. Yappari gaijin!"
j.onions@computer-science.nottingham.ac.UK (Julian Onions) (01/09/90)
It all seems to me that there is a lot of effort going into brain damaging protocols like RFC-822 just to work around broken DNS implementations. In the end, DNS has to provide the service and whilst pragmatic workarounds are OK for debugging, fixing them in concrete seems silly. Surely the solution is improving the DNS rather enforcing the use of IP addresses in mail addresses. If you allow escapes all the time so that the DNS can perform poorly, it will most likely continue to perform poorly. Yes - it may be occasionally useful to be able to directly aim mail at an IP address - but is it worth enforcing this capability. I might make the same claim that if I have a machine with a broken ARP mechanism it would be useful to mail directly to an ethernet address without requiring IP or names - but the solution is to fix the ARP implementation. In the UK, we had a similar situation for our registry, the NRS. A few years ago, people were loath to use this database, rarely kept up to date and only registered new hosts in it when they remembered. Then in certain implementations of the mail software we started refusing to accept mail from sites that were not registered (if you're not willing to identify yourself, we dont want to know + its almost trivial to loose email in such situations). I won't say this changed things overnight, but people now realise if they want to be part of this community, they better play by the rules and there are few sites now unregistered and everyone makes use of the NRS now. One of the problems I see with the IP d-lits is that it really isn't smtp specific - no matter what the HR says. We run RFC-822 (which is what the question is really about) over several networks, each supporting their own style of d-lits. The natural course is to follow the HR which means I need to understand lots of different styles of d-lits now (IP, X.25, yellow book ...). Its painful after having split up a system into SMTP and generic RFC-822 components to then have to go and stick back into the generic components SMTP specific bits. I guess if you'd split the HR into RFC-821 specific things and RFC-822 specific things maybe this wouldn't have arisen. Perhaps another idea for a future HR. Julian.