Rudy.Nedved@CMU-CS-A.ARPA (03/05/84)
A large number of sites seem to handle "mail from:" command errors by issuing the command "mail from:<>" as the next command. Considering that alot of mail is forwarded and that any mail with a null return is "droppable" if an error occurs, I don't think this is a wise way of handling "mail from" errors for the user will not get an error message. The following is an example of this code: 220 CMU-CS-A.ARPA TOPS-10 SMTP server ready 1C(50)-2 HELO bazola 250 CMU-CS-A.ARPA MAIL FROM:<frodo.baggins@bonzo_land> 500 malformed local host name 'bonzo_land', for line 'MAIL FROM:<frodo.baggins@bonzo_land>'. MAIL FROM:<> 250 Mail okay. RCPT TO:<Joe.Smoe@cmu-cs-a> 250 Rcpt okay. DATA 354 Ready for mail. 250 Mail completed. QUIT 221 CMU-CS-A.ARPA TOPS-10 SMTP service terminating I can understand that the code was probably installed duringthe tcp transition days when alot of smtp servers were still "buggy" but I can not see a reason for it now. Is there some other reason or should I send mail to sites that have this "old code" installed? Thanks, -Rudy
MRC@SU-SCORE.ARPA (Mark Crispin) (03/05/84)
Rudy -
The TOPS-20 SMTP sender (part of MMailr) is one of those SMTP
senders who will send a MAIL FROM: with a null argument if the SMTP
server rejects the command. This is to maximize what chance the
message has of getting through. I think that this is completely
within reasonable fault-tolerance procedures.
I will resist any pressure to change it, until and unless CMU
is willing to undertake the responsibility of reliably delivering
any and all mail originating from any and all TOPS-20 systems on
the Internet.
-- Mark --
-------Rudy.Nedved@CMU-CS-A.ARPA (03/05/84)
Mark, I didn't even know that TOPS-20 was in the crowd of people doing this way of handling rejected "mail from" commands. It looks like it is a defacto standard then since Unix, ITS and TOPS-20 do it. I don't understand why people use this mechanism if they want their users to have their mail delivered or get an error message back. I consider the risk too high to take the chance with using a null-return or no-return path....sigh. Maybe it is the case that these same systems parse the headers if they don't have a return-path and try to use the address?? If so the picture doesn't seem so bleak afterall. Well back to work....I not going to bug anyone except for people around CMU. -Rudy
don.provan@CMU-CS-A.ARPA (03/05/84)
Rudy, Look at your example: your mailer is all set to reject the mail altogether because it doesn't like "bonzo_land". How can you be upset about the remote mailer sending you a blank field? Its first priority is to get the mail delivered. If you're going to reject the only from address it has, what else can it do? You aren't going to return an error message there anyway. I don't really understand why mail receivers are parsing this field so carefully, anyway. I've had several sites i couldn't get mail to because they tried to parse '"Provan Don%c"@LLL-MFE' and couldn't, so they rejected the mail. Its bad enbough that they can't parse it, but to reject some mail because a field that shouldn't ever get used can't be parsed is silly. I wasn't smart enough to think of sending an empty address if it wouldn't take my real address, but now that it's been suggested, I think I'll add it. Frankly, I think the only legal error to a mail command should be "too busy to send mail now." I don't think it makes sense to reject it because of a syntax error.
MRC@SU-SCORE.ARPA (Mark Crispin) (03/06/84)
Rudy -
The problem is that it is a "de facto standard" to reject
MAIL FROM: commands for the slightest bogosity (even if the
bogon turns out to be at the SMTP server's end!). A number of
SMTP servers reject a-d-l's, for example. Still others reject
mail from "unknown hosts" when the problem is that the SMTP
server's host table is out of date. Yet another problem is
that many (most?) SMTP servers reject bracketed host names.
There are a number of "nameless" TOPS-20s which talk TCP/IP
and use their bracketed address forms as a name (e.g. [1.2.3.4]).
This is valid according to the standard and TOPS-20 fully
implements it, but try convincing a large number of SMTP
servers of that!!
I won't even go into the details of how to reply or return
messages in these cases (other than "implement the standard").
-- Mark --
-------MRC@SU-SCORE.ARPA (Mark Crispin) (03/06/84)
Don -
I take the middle ground. I think it is completely alright
to reject a MAIL FROM command because of a syntax error PROVIDED
that the syntax parser COMPLETELY implements the standard. That
includes:
. all forms of quoting
. source path route lists
. bracketed or #'d host addresses in lieu of host names
Very few SMTP servers do. I believe TOPS-20's SMTP server
does (if it doesn't, it's a bug because all the code is there).
I don't think an SMTP server should try to validate a host
name in a MAIL FROM command other than checking it for syntactical
validity. RCPT TO: is a different matter entirely.
-- Mark --
-------solomon@wisc-crys.ARPA (Marvin Solomon) (03/06/84)
I can't resist putting in my two bits. An important principle in mail systems is the notion of responsibility. If we want reliable mail systems, then we should design them so that throughout a message's lifetime, there is always some module responsible for it. When a server SMTP accepts a message, it is taking responsibility for that message. If for some reason it can't deliver the message to the recipient, it has the responsibility to return it to the sender. If it has reason to believe that it is being asked to accept a piece of mail that will be unreturnable, it has every right (indeed duty) to reject it. Otherwise, it may end up with no alternative but to drop the message on the floor--the very worst thing to do in any mail systems. The old BBN SMTP server (used with many Berkeley 4.1 UNIX systems) got a lot of flack (righly) for being too promiscuous in what it would accept; it would take just about anything, and figure out later what to do about it: MAIL FROM: !random@@garbage? 250 Fine and dandy RCPT TO: >you got to be kidding> 250 You betcha DATA blah blah blah . 250 Yes sir boss! I would much rather see mail bounce back to the sender if something goes wrong, than to have it flush down a black hole. If the server doesn't like the MAIL FROM address, the sender should take the rejection gracefully, and inform the sender that something is wrong. The sender (if he is a naive user) will yell at his mail system maintainer, who will see what's wrong and fix it. The idea of substituting "Postmaster" has a lot to recommend it, but if that's rejected (perhaps because it's the host name, not the local part, that's at issue), the sender shouldn't cram the mail down the receiver's throat. Null return addresses should only be used for the error messages themselves. If many (most?) SMTP servers are broken, they should be fixed, not coded around by breaking the senders as well.
don.provan@CMU-CS-A.ARPA (03/06/84)
Mark, Why should you ever reject it because of a bogus Mail From field? All you do by that is make sure the receiver doesn't get the mail. Of all the parties involved, the receiver is the one that can't possibly be at fault, so why limit the sevice you provide him? I agree that bells and wistles should go off all over the place, but not at the expense of delivery.
dpk@brl-vgr.ARPA (Doug Kingston) (03/06/84)
There are two different philosophies being used here. One says "Deliver the message at all costs", while the other says "Make a reliable deliver, or return it". The first is the method used by people that will give you a null return addresss (MAIL FROM:<>) while the second is the more conservative stratagy and gives you a better guarantee that you will know that the message was delivered (or not). MMDF (the system I maintain) is a more conservative mailer. We rigorously adhere to the transfer of responsibility model and we always give a return address (even it is the postmaster address). We do not attempt to supply alternate MAIL FROM addresses, and as it turns out we now almost never get rejections based on the MAIL FROM address. This was not true when the net first changed protocols though. Mark and others are not wrong in what they are doing, it just shows a difference in priorities. Cheers, -Doug-
Rudy.Nedved@CMU-CS-A.ARPA (03/06/84)
don, The problem is that large number of sites including CMU's Unix machines relay mail to another site and do not include their name in the return path. In the example I gave the sender was something like "bazola" and it was NOT in the mail from: line. The return path of "@bazola:<user>@bonzo_land" will work in the CMU-CS-A server (independent of whether it is in the host table) and so will "@[78.7.8.9]:<user>@bonzo_land" but since my mail system knows that hosts that are in the local domain have names that contain the character set A-Z and period it rejects the mail. The reason behind this was I was getting some real bizarre garbage host names that sometimes look like data or internal queueing data from the remote host. I suspect that a large chunk of mail systems can not handle funny characters that "happen" to be the queue file delimiter....like our Unix machines using colons can not simply insert the return path into the queue file...some conversion has to be done. The other problem I have seen is that if I add the connected site name to the return path if it is not there then when the mail is rejected, the site I did this service for rejects the error notifcation. I think what I will do now is change the mail server so that it adds the connecting site host name (or address) and if an error occurs it tries to send it back to the correct address and if that fails it replaces the address with Postmaster@<original connecting site>. As Doug Kingston has pointed out...we have two design philosphys in the mail world....I didn't realize this before and I am glad I sent mail asking before starting to shoot at sites that are different. My apology for the length of this message. -Rudy
RICH.GVT@OFFICE-3.ARPA (Rich Zellich) (03/06/84)
Re the mention of two different philosophies: Remember, please, that there is an authentication issue involved, too. Perhaps the "deliver at all costs" philosophy should quietly begin disappearing (at least in the MilNet environment), since there is a very large, and growing, community of users using mail for business purposes as well as the older uses for technical (and social) purposes. -Rich
steve@brl-bmd.UUCP (Stephen Wolff) (03/06/84)
> Perhaps the "deliver at all costs" philosophy should quietly begin > disappearing (at least in the MilNet environment) ......... Why the (apparent) double standard? MILNET people don't NEED reliable mail service? Or at least not if `business' (commercially) related? Can you explain, please? I'm puzzled. -steve
farber@udel-ee.arpa (Dave Farber) (03/06/84)
As some one who has run an experimental mail relay for the Military for many years (!!), let me assure all that they NEED reliable mail and deliver at any cost. You every see a red faced 4 star? Dave ps Steve, I know you know. It should be to: Rich, copy you.
gross@dcn7.ARPA (03/06/84)
I'm also in favor of phasing out the 'deliver at all costs' philosophy since it can cause as many problems as it solves. Are there any counterbalancing arguments out there? Why leave Milnet out? Phill -------
wcwells%ucbopal.CC@Berkeley.ARPA (William C. Wells) (03/08/84)
Military message systems operate on three basic principles: reliability, speed, and security. Of the three, "reliability is paramount". I think you will find that an electronic mail system that permits messages to "drop into a black hole" will not be acceptable for Defense Data Network (ie. MILNET) use. Mail transport agents should be responsible for ensuring the FROM in SMTP and the "From" in the mail header are correct both when received and when transmitted. This may require that gateway mail transport agents modify the address when the message is transmitted by a gateway into a different mail domain or mail system. For non-Internet mail addresses, this means transforming the address into an address that is acceptable to the Internet world. It may mean adding the source "route" (eg. @host.domain:) of the gateway mail transport agent to the front of the From address, or changing the address into the form: "off-net-address"@mail-gateway-id.registered-top-domain-name where the address to the right of the "@" sign is a valid Internet mail domain name. Receiving mail transport agents should check the FROM field, if the syntax is correct, but the domain name is not, then they should add the domain name of the sending mail transport agent to the front of the source "route" in the address to ensure a reply path. --- Hmmmm. That would imply the addresses of the form: <@mail-gate.Internet-top-domain:local-address@hostid.non-ARPA-domain-name> for example: <@mail-relay.ARPA:userid@hostid.local-netid> should be legal within the Internet mail world. That is, if the first domain-name in the source "route" is known and valid within the current mail domain, and the syntax of the address is correct, then the address should be accepted by the receiving mail transport agent. Bill Wells, Computing Services, UC Berkeley wcwells@Berkeley.ARPA or ...!ucbvax!wcwells