Re: procmail and kmail

["Stephen J. Turnbull" <nospam [at] sk.tsukuba.ac.jp>]

>>>>> "Al" == Al Hudson <eah106 [at] york.ac.uk> writes:

On Fri, 18 Feb 2000, Stephen J. Turnbull wrote:

    >> If my guess based on Edit | Preferences | Mail & News | Mail
    >> Server dialog is correct, Netscape forwards all mail to a
    >> "smarthost" for relay by internally implemented SMTP; it does
    >> not use /usr/lib/sendmail directly at all.

    Al> Hmm, seems so. I guess you can setup smtp on localhost, and
    Al> use that, but seems a trifle o.t.t...

Why?  This is just the standard "Unix filter" usage.  This allows you
to use an SMTP server (eg, sendmail) on the local host if you want
queueing, or you can have Netscape send it directly if (like many,
perhaps the majority, of Netscape users) you are invariably online
when browsing or otherwise doing things that cause you to send mail,
or you can direct it to a smarthost.

This just means that Netscape has great flexibility in how it handles
outgoing mail without needing to deal with anything except
implementing a connection to the TCP/IP SMTP port (trivial, Netscape
has to do TCP/IP anyway) and the SMTP protocol itself, which would
occupy maybe 2k of C code if you wanted it to be bullet-proof.

Queueing in Netscape, on the other hand, would involve a host of extra
problems.

    >> [1] This is not a criticism of any users; anybody who is smart
    >> enough to choose Linux is smart enough to use it in my book.
    >> It is a criticism of the assumptions made by the scripts.

    Al> I would say, in defence of scripts, most of the good ones work
    Al> 99% of the time. If they don't work for you, then you're
    Al> obviously doing something so particular that you ought to know
    Al> what you're doing anyway. But true, bad scripts can be worse
    Al> than no scripts....

I think that's unfair to users.  Scripts very often refuse to
configure (or worse, misconfigure) the most recent hardware.  I don't
see why users who wouldn't be expected to know how to configure old
hardware should be expected to know how to configure new hardware.

Scripts also often lag the most recent versions of standards or are
not flexible enough to handle some new wrinkle (eg, a different
authentication scheme or special parameters for some ISP).

The point is that scripts typically make a lot of pretty restrictive
assumptions.  This is often reasonable when you just want to drop in
to an environment that expects Windows levels of stupidity from the
clients.  But they proceed to break in hard-to-diagnose ways outside
of such protected environments.

I agree with you that the good ones work most of the time, maybe even
99% of the time.  But when they don't, that's when the people who need
them most are left hanging.

-- 
University of Tsukuba                Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences       Tel/fax: +81 (298) 53-5091
_________________  _________________  _________________  _________________
What are those straight lines for?  "XEmacs rules."
---------------------------------------------------------------------
Sheffield Linux User's Group - http://www.sheflug.co.uk
To unsubscribe from this list send mail to
- <sheflug-request [at] vuw.ac.nz> - with the word 
 "unsubscribe" in the body of the message. 

  GNU the choice of a complete generation.