Nostalgy corner: ED

If you don't get this, you're:

1. Not into UNIX
2. Not old.

  From: patl@athena.mit.edu (Patrick J. LoPresti?)
  Message-ID: <1991jul11 .031731.9260="" athena.mit.edu="">
  Sender: news@athena.mit.edu (News system)
  Subject: The True Path (long)
  Date: 11 Jul 91 03:17:31 GMT
  Path: ai-lab!mintaka!olivea!samsung!zaphod.mps.ohio-state.edu!think.com!snorkelwacker.mit.edu!bloom-picayune.mit.edu!athena.mit.edu!patl
  Newsgroups: alt.religion.emacs,alt.slack
  Organization: Massachusetts Institute of Technology
  Lines: 95
  Xref: ai-lab alt.religion.emacs:244 alt.slack:1935



  When I log into my Xenix system with my 110 baud teletype, both vi
  *and* Emacs are just too damn slow.  They print useless messages like,
  'C-h for help' and '"foo" File is read only'.  So I use the editor
  that doesn't waste my VALUABLE time.



  Ed, man!  !man ed



  ED(1)  UNIX Programmer's Manual  ED(1)



  NAME
 ed - text editor



  SYNOPSIS
 ed [ - ] [ -x ] [ name ]
  DESCRIPTION
 Ed is the standard text editor.
  ---



  Computer Scientists love ed, not just because it comes first
  alphabetically, but because it's the standard.  Everyone else loves ed
  because it's ED!



  "Ed is the standard text editor."



  And ed doesn't waste space on my Timex Sinclair.  Just look:



  -rwxr-xr-x  1 root       24 Oct 29  1929 /bin/ed
  -rwxr-xr-t  4 root  1310720 Jan  1  1970 /usr/ucb/vi
  -rwxr-xr-x  1 root  5.89824e37 Oct 22  1990 /usr/bin/emacs



  Of course, on the system *I* administrate, vi is symlinked to ed.
  Emacs has been replaced by a shell script which 1) Generates a syslog
  message at level LOG_EMERG; 2) reduces the user's disk quota by 100K;
  and 3) RUNS ED!!!!!!



  "Ed is the standard text editor."



  Let's look at a typical novice's session with the mighty ed:



  golem> ed



  ?
  help
  ?
  ?
  ?
  quit
  ?
  exit
  ?
  bye
  ?
  hello? 
  ?
  eat flaming death
  ?
  ^C
  ?
  ^C
  ?
  ^D
  ?



  ---
  Note the consistent user interface and error reportage.  Ed is
  generous enough to flag errors, yet prudent enough not to overwhelm
  the novice with verbosity.



  "Ed is the standard text editor."



  Ed, the greatest WYGIWYG editor of all.



  ED IS THE TRUE PATH TO NIRVANA!  ED HAS BEEN THE CHOICE OF EDUCATED
  AND IGNORANT ALIKE FOR CENTURIES!  ED WILL NOT CORRUPT YOUR PRECIOUS
  BODILY FLUIDS!!  ED IS THE STANDARD TEXT EDITOR!  ED MAKES THE SUN
  SHINE AND THE BIRDS SING AND THE GRASS GREEN!!



  When I use an editor, I don't want eight extra KILOBYTES of worthless
  help screens and cursor positioning code!  I just want an EDitor!!
  Not a "viitor".  Not a "emacsitor".  Those aren't even WORDS!!!! ED!
  ED! ED IS THE STANDARD!!!



  TEXT EDITOR.



  When IBM, in its ever-present omnipotence, needed to base their
  "edlin" on a UNIX standard, did they mimic vi?  No.  Emacs?  Surely
  you jest.  They chose the most karmic editor of all.  The standard.



  Ed is for those who can *remember* what they are working on.  If you
  are an idiot, you should use Emacs.  If you are an Emacs, you should
  not be vi.  If you use ED, you are on THE PATH TO REDEMPTION.  THE
  SO-CALLED "VISUAL" EDITORS HAVE BEEN PLACED HERE BY ED TO TEMPT THE
  FAITHLESS.  DO NOT GIVE IN!!!  THE MIGHTY ED HAS SPOKEN!!!



  ?

Turning off opportunistic client TLS in sendmail

It appears that sendmail, during mail delivery, tries TLS if the receiving server offers it. Fair enough, I can perhaps send over an encrypted channel, so I am going to try. Sounds harmless, right? Wrong.

See the follwoing SMTP dialog:

... Connecting to mail.snafu.com. via esmtp...
220 mhnicosi-unix.fubar.it ESMTP
>>> EHLO mx1.example.it
250-mhnicosi-unix.fubar.it
250-AUTH=LOGIN CRAM-MD5 PLAIN
250-AUTH LOGIN CRAM-MD5 PLAIN
250-STARTTLS
250-PIPELINING
250 8BITMIME

>>>; STARTTLS
220 2.0.0 Ready to start TLS
EHLO mx1.example.it
... Deferred: Connection reset by mail.snafu.com.
Closing connection to mail.snafu.com.

See the problem here? The receiving server shuts down the connection - possibly because it's not prepared to negotiate TLS with our server, sendmail queues the message and, on the next delivery, will go through the same motions in perpetuum.

I got the solution from this post of Mike Berggren. Basically, either stick

• Try_TLS: No 

(global) or

• Try_TLS:[host designation] NO

(per host) in /etc/mail/access.
Mike points out that adding the M=S flag to the CLIENT_OPTIONS macro in sendmail.mc has the same (global)) effect:

• CLIENT_OPTIONS(`Family=inet, M=S, Addr=1.2.3.4’)dnl

I did not try that though, as the first solution warks well enough, and my sendmail.mc does not use the client_options macro anyway.