honey@princeton.UUCP (code 101) (09/07/84)
I don't want to seem curmudgeonly here, but I get irritated by the headers that sendmail tacks on to my messages. The message I have in mind is the one I send, not one that is expanded (and sometimes perverted) by a smart mailer. With that in mind, here are the changes I made to princeton's sendmail.cf. Mix and match as you see fit. In the Header definition section, make the Received: header depend on the M flag (so that it can be turned off later). # HReceived: $?sfrom $s $.by $j ($v/$V) # id $i; $b # H?M?Received: $?sfrom $s $.by $j ($v/$V) id $i; $b In the local/program mailer section, eliminate the flags that request Date:, From:, and Message-Id: (and now, Received:) headers. # Mlocal, P=/bin/mail, F=rlsDFMmn, S=10, R=20, A=mail -d $u # Mprog, P=/bin/sh, F=lsDFMe, S=10, R=20, A=sh -c $u # Mlocal, P=/bin/mail, F=rlsmn, S=10, R=20, A=mail -d $u Mprog, P=/bin/sh, F=lse, S=10, R=20, A=sh -c $u In the uucp (flutter my heart!) mailer definition, terminate with extreme prejudice flags that request Date:, From:, and Message-Id: (and now Received:) headers. Get rid of the h and u flags, thereby enabling upper-to-lower case mapping of host and user names. (Anyone who mails to Princeton!Honey deserves what he gets, but he won't get it here.) Get rid of the size limit, which otherwise gets in your way at precisely the moment when it hurts most. # Muucp, P=/usr/bin/uux, F=sDFMhuU, S=13, R=23, M=100000, # Muucp, P=/usr/bin/uux, F=sU, S=13, R=23, My uux line is substantially changed, using a lot of honey danber- ism's: -b asks the remote uuxqt to return stdin (in this case the mail) to the requester if the remote execution fails, -a$f gives the address of the requester (relative to this site), -gA sets the grade of this transaction to A, so that this job is transmitted (and remotely executed) ahead of, e.g., rnews (for which I specify -gz in the sys file). Most versions of uucp can't handle -b and -a. 4.2bsd uucp understands the -g flag, but may not treat it quite right. (Hey, just between you and me, it's not clear that honey danber treats grades right.) Finally, I removed the -r flag, which requests that uux spool the work but not initiate a call. That was just plain nasty, Eric. # A=uux - -r $h!rmail ($u) # A=uux - -a$f -b -gA $h!rmail ($u) Say Gene, may I borrow your soapbox for a few lines? Thank you. I have here in my hand an envelope, on the back of which is scrawled "> 1 megabyte per day"; that's how many bytes will be saved if we all make these changes. And there may be bigger savings to come if I read the sendmail documentation correctly: we may be able to do away with unsightly headers altogether! Peter
mark@cbosgd.UUCP (Mark Horton) (09/07/84)
While Peter makes some good suggestions for things that are reasonably local configuration options, I must point out that Date and From are required by RFC822, and Message-ID and Received are strongly recommended. Thus, if you make the changes to remove these lines, you will break your conformance to the mail standard. I am not convinced that these headers really make any difference in the disk space occupied by mail or the time to transmit mail over phone lines. The numbers that really matter for mail are the number of messages, not the number of bytes in the messages. (Of course, a 50K file will make a difference, but most mail messages are quite short.) Saving 100-200 bytes on a message cuts down transmission time by about one second per message at 1200 baud. Considering the time to negotiate the transmission of each message file, this second is insignificant. Now, consider the benefit of the lines. In addition to conformance with the standard (which the UUCP project has adopted as a UUCP network standard), these lines provide an audit trail, so that when you find a strange message dropped on the floor and can't figure out what happened, these lines make it much clearer what happened, so you can deliver the message and/or track down the problem. We all know how reliable UUCP mail is and how often this kind of situation arises - it seems well worth an extra 10 cent charge on 10% of your phone calls. The real reason people object to the verbose 822 headers is that they, as humans, don't like to read them (or watch them fill up their screen at 1200 baud.) This is easily handled by instructing your user interface not to display lines you don't like. I have the line ignore received status via message-id date sent-by in my .mailrc for exactly this purpose. Mark Horton
honey@down.FUN (code 101) (09/09/84)
Far be it from me to encourage people to ignore the ARPA standards; would that we could. However, I am rigidly opposed to their wholesale imposition on the non-ARPA world. Observe that my configuration changes pertain only to the local and uucp mailers. ARPA mailers can (and (grumble) probably should, because they (grimace) must) add any headers they like (or need). My remarks concerning disk/transmission overhead were not meant to sway anyone; on the other hand, if everyone would be so kind as to send me the one or two blocks per day they give up to Brother Allman, I will never have to buy another disk. (This is know as the Roome-effect, well known to USENET old-timers.) I have more than enough of an audit trail in my uucp logs. Mark's sarcastic reference to uucp reliability is more than a little ironic; I should think that anyone so fortunate as to be running a vastly improved version of uucp would show a little appreciation, rather than spewing slander. Furthermore, the only benefit that I can see in dropping an audit trail in my mailbox is to trace back to the broken version of sendmail that created the havoc in the first place. Finally, telling people to use mailers unavailable (or repugnant) to them is not a solution. I repeat my central thesis: The message I have in mind is the one I send, not one that is expanded (and sometimes perverted) by a smart mailer. If you have some other notion when you send electronic mail, I encourage you to build your ideas into *your* mailer, but not, thank you, into mine. As an aside, I use a substantially modified version of the Berkeley 2.17 mailer (the last Berkeley mailer that actually works). I ignore message-id, status, received, article-id, article-i.d., date-received, lines, path, posting-version, relay-version, posted, in-reply-to, resent-date, resent-from, resent-message-id, via, references, organization, and full-name. Get the picture? Peter