Here it is:

http://www.troubleshooters.com/lpm/201202/201202.htm

Apparently this is timely and topical. As Kmail forces people to
Kmail2, users desert Kmail in droves. One guy on the Claws-Mail list,
successfully converted to Kmail2.

Thanks to all the SVLUGgers who helped me get this new email system put
together.

SteveT

Here it is:

http://www.troubleshooters.com/lpm/201202/201202.htm

Apparently this is timely and topical. As Kmail forces people to
Kmail2, users desert Kmail in droves. One guy on the Claws-Mail list,
successfully converted to Kmail2.

Thanks to all the Pub-Forum People who helped me get this new email
system put together.

Gary C: Note that once in a while I bitch about software not made by
Microsoft, Apple, Google or Sony!

SteveT

Oh, this is going to be popcorn-worthy.  Folks, if you haven't read one
of Steve Litt's excellent articles at troubleshooters.com, you really
should.  Every one of them I've seen so far has been thoughtful and well
worth the time.

Steve, mutt _still_ works, by the way.  ;->

(Me, I just stick with mutt under screen, running 24x7 on my receiving
SMTP host.  Who needs an MRA when you can ssh in and read directly from
a local mail spool?)

However, you disappointed me by still, in 2012, holding a torch for
Reply-To munging, which not only was always a dumb idea, but also
lost for good at IETF, starting eleven years ago. http://linuxmafia.com/~rick/faq/?page=netiquette#replyto

Thank you Rick!

OOPS, I actually meant to imply in the article that not only does mutt
still work, but it's excellent. If there's any part of that article
omission, please let me know where, and I'll fix it.

I'm not man enough to set up an SMTP server. I'm ESPECIALLY not man
enough to set up a sendmail server. But anyway, I can use
Fetchmail->procmail to deposit to my local mail spool, and read that
from Mutt. When the dust dies down, I'll be checking out mutt's IMAP
connectivity, which I hear is pretty good. I might have mutt be my
secondary email client.

:-)

I eliminated that part of it, not because I don't still believe what I
said, but because I don't want to open up a two front war, and I'm
going to be getting enough grief from KDE advocates :-).

If anyone really wants to discuss my belief that when you reply to a
mailing list post it should default to the list, not the sender, we can
do that in another thread, but that wasn't the main point of my article.

If most modern email clients automatically send to the list in the
removed).

Thanks

SteveT

Good boy.  mutt(1) is excellent, though even after ten years I still don't
have a handle on all the keyboard shortcuts.  It needs a vi mode.  ;)

I'm a KDE advocate and I can't even stand behind Kmail.  I use Thunderbird
and/or mutt(1) on BSD, but it's rare for me to be using email on anything
other than mobile devices these days, so I guess that point is moot.

That's the point behind reply-to-all, and why I set it to default on all
my mail clients.  I've been in heated debates on many mailing lists in the
past where people didn't know how the hell to use reply / reply all, even
internally where I work, and I don't think anyone ever learned.  Grumble
grumble I'm an old Unix fuddy-duddy who doesn't know anything.

--Andrew

I'll second Rick's recommendation of Steve's article(s) -- that page
is a great overview of mail architecture even if you don't care
about kmail.  Recommended reading for anyone who's unclear on things
like the difference between the MTA, MUA, and MDA, or how SMTP, POP
and IMAP work, or what procmail is for.

That's what I do -- though fetchmail->procmail->lots of local folders,
not just a single spool file. Definitely easier than setting up
sendmail or postfix.

My folder tree is just a tree of mbox files -- so I'm not locked in,
and can switch to any mailer that understands mbox. And I can back up
my folder tree using cp -a or rsync. (Such backups confuse mutt's
idea of which folders have new mail a little bit since there's no way
to copy files without changing atime, but that's life with mutt.)

I use mutt's IMAP on occasion, to check in with gmail or to make a
quick mail check from a machine where I'm not set up to run fetchmail.
It works fine for simple stuff like that, though status changes like
read/unread don't seem to persist.

(Controlling myself and not adding a paragraph on reply-to. :-)

    ...Akkana

IMAP is nice.

Today even my paranoia can't find any good reason to become a
vi or mutt master (unless you already are).
These tools have 2 main advantages: low bandwidth need and
availability.
But you don't have to become a vi/mutt master to use vi or mutt
productively in the rare circumstances where you don't have
alternatives.

With the proliferation of mobile devices, screen size and interface
may be a more challenging constraints.

GUI tools have higher screen to brain bandwidth.
A finer organization of screen real estate, fonts, colours... helps
your brain to grasp information more efficiently.

On the other side there are two unfortunate coincidences:
- most GUI tools forget that a keyboard has generally higher
  bandwidth and expressivity than a mouse
- most GUI tools are monolithic programs that went to far from the
  *nix philosophy of glueing together several other tools

This generally translate into making them less scriptable, less
ductile and less "available".
You shouldn't need to get used to a different IDE when you switch
from programming in python to programming in heskel or when
switching from arm to avr. Your compile options shouldn't end in an
XML file that your compiler is not able to understand directly.

I haven't had the time to switch my habits from per-divided mail to
post-divided mail and my prejudices don't give me enough reasons to
try.

The advantage of one mail spool is you know where new mail is going
to arrive and you don't need to see a tree structure to navigate
your recent mails.

The advantages of having your mail pre-divided in folders are many,
procrastination alone is enough to justify this approach.

Sooner or later anyway you'll have to archive your email in folders.

What's missing for email nirvana is a more mature support for sieve
and IMAP subscriptions.

And no... there is no chance I'll wake up as a hipster developer
with a Mac.

--
Ivan Sergio Borgonovo http://www.webthatworks.it

LOL. Don't get me started.

Seems like every non-Linux get-together, a Mac guy tells me when I grow
up I'll be using a Mac.

:-)

SteveT

mutt in an xterm has _awesome_ screen to brain bandwidth.  

A deliberate absence of sender-specified fonts and colours in e-mail is
not only helpful but absolutely crucial to good aesthetics, legibility,
and in some cases basic sanity.  (I mean, have you _seen_ what people
do to mail, given the ability to specify formatting, not to mention
inline Javascript and other garbage?  No thanks.)  mutt in an xterm
permits _me_ to specify the font, colours, etc.

that _of course_ includs procmail sorting and re-filing my mail into
multiple places that suit my needs.  It all just happens to stay on my
MTA host -- which is where my substantive computing occurs, by
preference.

That way, it really doesn't matter what machine I'm typing and
screen-viewing on, as for mail purposes the local console is just an
ssh-enabling device permitting me to reach across the Internet to where
I do my real work.  Doesn't fit everyone's working styles, but it Works
for Me[tm].

It helps to not be aware that you shouldn't.  ;->

(The default setup of exim4 for general Internet usage is very manageable,
although the default antispam is insufficient in 2012.)

Your problem, there, is that your conceptual framework is wrong and fails
to match the reality it purports to describe -- and it rests on the
erroneous assumption of there being a single all-purpose mail action
called 'reply'.

You actually already know the latter is wrong, but I keep hearing this
becomes a mantra.

Your boss sends e-mail to you and your four co-workers, asking that each
department member reply and brief everyone else.  Do you use 'reply'?
No, you don't, unless you want to be a doofus.  You use reply-all.

So, you and everyone else who's ever repeated the justification you have
trotted out is fully aware that his/her and everyone else's e-mail
client software has separate reply-sender and reply-all commands that
are used for separate purposes (not just 'reply') -- but suffers an odd
momentary amnesia whenever mailing lists are discussed.

Briefly:  Group reply command when replying to everyone, individual
reply command when replying to sender.  Works everywhere, never violates
the principle of least surprise.

Getting to your conceptual framework:  When you say 'default to the
list', you mean 'override what the sender specified without consulting
him or her, and autoinsert a control intended for other uses entirely'.
When you say 'default to the sender', you mean 'leave the message the
least surprise.  If the user had intended reply-all, the user would have
used reply-all.

Here, you take a running leap further based on your misparse of reality:
Modern e-mail clients automatically do reply-all when the user says
reply-all.  Modern e-mail clients automatically do reply-sender when the
user says reply-sender.  

If downstream mailing sofware doesn't presume to fool with what the
going to reach the intended recipients.  If downstream software cleverly
reply-sender command but I'm sure that in _this_ context, he/she really
intended to do reply-all', then senders who really _did_ intentionally
use the reply-sender command are going to be massively and perhaps very,
_very_ unpleasantly surprised by the message reaching a very public
audience when he/she intended a private one.

Often what proponents _really_ mean is 'I want the world to get
simplified so that I can ignore the semantic distinction between the
separate reply-all and reply-sender actions.  I want to pretend that
there is just 'reply', and that 'reply' will always automagically figure
out what I was thinking and always Do What I Mean.

So, in order to cater to people who don't want to think about the
difference between two very different things, they ask that
mail-handling software send privately addressed mail out into the
public.  But, hey, what could possibly go wrong?  ;->

I personally do enjoy being on mailing lists that have munging enabled.
Mutt's ability to autoignore it means I'm never adversely affected
(except in a very minor way when munging prevents me from using the
header for its _intended_ use), and meanwhile I get to see other
people's embarrassing accidental public postings of private mail.  It's
a nice bonus when the victims are munging advocates, which actually
happens quite frequently.

The sad part is every mail client I've used with the exception of Pine
(that'd be Thunderbird, claws-mail, Mail.app on Mac and iPhone, the Gmail
Web interface, Kmail, Evolution, Eudora, GNUstep's mail client, and even
Outlook) can all be set to automatically reply-all.  That effectively
allows
you to oversimplify and make the hilarious mistakes, without having to
bother mailing list admins about reconfiguring it so that *everyone* is
suddenly forced to deal with your oversimplifications and ineptitude.

*takes off the "I really hate people who don't grok email" hat*

Sometimes I wonder why user education classes even exist.  I also wonder
why
people are afraid to click "edit->preferences" in GUI apps.

Kudos on not just succumbing and putting your email on gmail.  This blog
post from Herald Welte sums up what I feel about people who host their
own site, but not their own
email. < http://laforge.gnumonks.org/weblog/2011/06/11/#20110611-gmai[..] >

--
Raj Shekhar
-
Simon: I swear... when it's appropriate.
Kaylee: Simon, the whole point of swearing is that it ain't appropriate.
-
Read the latest at my blog: "gitosis hint: does not appear to be a git repository" < http://rajshekhar.net/blog/archives/415-gitosis-hint-does-no[..] >

Running your own MTA is not that difficult.  (Steve Litt's gibe
extra hurdle in 2012, that was not present when I and innumerable other
people, unaware that we weren't supposed to be able to do it, did it
with no difficulty whatsoever in earlier decades, is antispam.

You can put up a spare machine with distro-default configuration of
Apache httpd on a static IP, and, voila!  You have a perfectly
functional Web server with no significant problems.  By contrast,
distro-default MTA packages... sure, they work fine:  On a Debian box
with static IP[1], you answer a couple of questions to create Exim4's
initial configuration, and it works, _but_ then the continual barrage of
spam starts.  Thus, in 2012, running your own full-service MTA requires
more work than the 'forehead install' beloved of Linux tirekickers (keep
hitting the spacebar with your forehead until package installation
completes, then congratulate yourself on being an AW3SUM H4XX0R D00D
who's able to run Linux).

So, you have to tinker a bit to make your MTA smarter than it comes out
of the box -- but it's still just not particularly difficult.

Longtime SVLUG member Karsten Self looked around a few years ago and
found the _true_ lazy-man's alternative to running an MTA.  He's now
reachable at karsten*******.  ;->

[1] DynDNS fans will object to that static-IP qualifier.  To them, I say
'Good luck!'

I used to run my own mail server, but anti-spam was becoming somewhat of
an uphill battle.  Also, I was a bit annoyed having the reliability of
my e-mail depend on the reliability of machines that I was managing on
my own time.  (In this case, on my home internet connection as well.)
While I could have just migrated up to the co-lo server I was using at
the time, I to decided to just outsource it.  That way someone would be
keeping up with anti-spam and availability of my e-mail as their job.

Of course not wanting to "give it all to Google" (like pretty much
everyone else I knew), I went with another provider that I actually pay
for, and their motivation to support me is not based on selling ads on
top of my e-mail experience.  (It also helped that they were running a
similar software stack to what I was running myself, so all my filter
configurations migrated nicely.)

--
----------------------------
Derek Konigsberg
dkonigsberg*******
----------------------------

I agree with both of you, BUT ...

The biggest problem I found with running my own MTA on a home server
was when I'd find myself out of town, and suddenly the server is
unreachable. Did the DSL go down and the provider needs a phone call?
Does the DSL modem just need a power cycle? (Happens pretty regularly.)
Is there a power failure at home? Did some package from a recent
security update hork networking? (Happened twice, once with bind9,
once with perl -- and no, we weren't pulling updates while we were
away; these were from manual updates a day before we left that
turned out to have delayed effects.)

Running an MTA isn't that hard. What's hard is debugging network
failures when you're not physically there and can't ssh in.
I finally gave up and moved to an ISP. (Not gmail.)

    ...Akkana

If you'll pardon the cliche, the key is to fight smarter, not harder.
Excellent place to start is J.P. Boggis's 'EximConfig' suite of tweaks
to Exim4.

'Eximconfig' on  http://linuxmafia.com/kb/Mail

I don't know what your notion of MTA antispam was, and mean absolutely
no offence, but in my experience a lot of people work hard but not very
intelligently at the problem.

If your Linux box isn't reliable, you have bigger problems than e-mail.

My server pretty much runs like a champ, and I neglect the hell out of
it.  The only antispam task that's not fully automated is occasionally
feeding some recent spam and some recent non-spam to the Bayesian
classifier.  Everything else runs itself.

Indeed, the advantage of using services you pay for is that you are the
customer rather than the product.

If you have to worry about your provider, you might just have the wrong
one.  With Mike Durkin's Raw Bandwidth Communications, I know that the
service is about as reliable as aDSL can be, given that Mike is stuck
(for now) with putting his DSLAMs on PacBell^WSBC^WAT^T infrastructure
that occasionally shoots him in the foot.

Running my Internet services has, over the decades, been stupidly easy,
really.  If it weren't, I'd never be able to have gotten away with it,
given my work schedule.

Anyway, nothing wrong with colo or VPS solutions, either.  (/me waves to
Luke S. Crawford.)

Well, it was actually as two-way sort of battle.  First, it was blocking
spam (and getting hit by the occasional endless Joe-job).  Second, it
was having to keep my server off other ISPs spam lists, simply because
it came from some IP range they might have once had issues with.  (this
would surface rarely, but would be a real problem when it did)

Actually, the real issue here was more of what Akkana was referring to.
Having reliability issues with my home internet connection when I was
not at home, with no way of doing anything about it.  At the time, my
co-lo solution had its own share of issues.  (Of course today, my VPS
provider gives me far less concern, and I think my current Internet
connectivity is more reliable, if I were ever to change my mind on
E-Mail hosting again.)

Absolutely.

--
----------------------------
Derek Konigsberg
dkonigsberg*******
----------------------------

Yeah, about blocking spam, that's precisely where I was saying most
folks keep trying to fight harder rather than smarter.  There are a lot
of really dumb, unworkable methods people keep trying to use, e.g.,
local IP blocklists, attempts to filter solely on whitelists and
blacklists of apparent senders, maintaining huge and overcomplex regexes
in Perl as a primary defence, and so on.

Again, studying the Eximconfig bundle and its docs can show you some of
the more intelligent defences.

Well, there, it makes a difference whose netblock you get allocated
Communications, so I got clean IPs that hadn't had a history of use by
spamhauses.  

However, although nothing prevents someone from operating an RBL with
totally unreasonable timeout and delisting policies such that your IP is
still disrecommended years after it was last guilty of spamming, in my
experience that's incredibly rare.  You might have misinterpreted the
standard way an RBL lets the world's sysadmins know it's shutting down:
by starting to issue block responses on any IP whatsoever.  Sounds
crazy, I know, but it turns out that's claimed to be the only way to get
people to cease querying a decommissioned RBL.

Again, if your Internet link has substantial and frequent reliability
issues, then you have bigger problems, and you might have the wrong
provider (***cough*** SBC ***cough***).

My aDSL sometimes annoyingly zones out for a few minutes, root cause
generally being either backbone BGP problems (observable by
tracerouting) or AT&T/SBC shooting Mike Durkin in the foot again.  But
it gets straightened out shortly thereafter.

Power outage?  Sure, about every other winter.  Praise be for journaling
filesystems, so it comes right back up.  Hardware failure?  Always a
possibility.  Non-crappy hardware, backups, RAID0, and a spare migration
server are your friends.

A lightning and wind storm destroyed my ancient (1998-era) VA Research
model 500 in 2009, shortly before I was due to be hospitalised for
surgery.  I had time to cut over to the standby and slightly less
ancient (2001-era) VA Linux model 2230 before I had to be admitted:
I had about three or four hours of downtime, total.

Oh, yes, good point! Even when I handled my incoming mail on the
home server, I still wasn't able to send out from that server --
I had to use a mail relay from some ISP or other, because too
many sites automatically blacklist all SBC DSL IPs, even static IPs
that have been unchanged for many years. Very annoying.

True enough -- we probably could have shopped around for another DSL
provider, hoping to find one not subject to blacklists.  Curiously,
Raw Bandwidth was our first choice way back when we first got DSL,
but they turned us down because we were too far from the exchange
(out here in the wilds of nearly-downtown San Jose). SBC was the only
DSL option.  But that was many years ago; we'd probably qualify now.

    ...Akkana

Yeah, I'm not the least bit surprised to hear that you cannot
successfully use _SBC_ DSL for that purpose.  (Let's face it:  That's
the lowest-end of all such offerings.  Sadly, as you say, sometimes it's
been the only DSL in a particular poorly served area.)

A likely reason for your problem is that your 'static' IP was allocated
from the middle of a designated dial-up or otherwise dynamic block, and
there's a long tradition of RBLs listing such netblocks going back to
MAPS's 'DUL' (dial-up list) RBL of the 1990s.

Anyway, if I knew a friend who had such a problem -- and I stress
-friend-, not just some person on a mailing list -- I could be easily
persuaded to let that person's MTA use mine as an outbound relay, at
which point that friend could add my server's IP to his or her DNS as an
MX, a part of the SPF entry, etc.

Well, you happened to be on the worst possible DSL choice.  (My opinion;
yours for a small fee and waiver of reverse-engineering rights.)