From: W. Greenhouse <wgreenhouse-sGOZH3hwPm2sTnJN9+BGXg@public.gmane.org>
To: ding-smP1P7uqpqc@public.gmane.org
Subject: Re: Any way to captuer smtp output when sending mail?
Date: Sun, 02 Nov 2014 23:55:14 +0000 [thread overview]
Message-ID: <878ujtkvj1.fsf@motoko.kusanagi> (raw)
In-Reply-To: <87zjca8m5k.fsf@dv.local.lan>
Harry Putnam <reader-kFrNdAxtuftBDgjK7y7TUQ@public.gmane.org> writes:
[...]
> Perhaps there are good reasons to do it and I would be better off
> spending my time getting setup for that.
>
> Any speed or cpu differences of note?
>
> Any other points infavor of all smtpmail.el?
As I see it, the pros of smtpmail.el are:
1. Fewer moving parts--sometimes following the "UNIX philosophy"
to the extreme for a problem like email means that it's hard to know
what has failed when you change something in your delivery pipeline
and it stops working:
Is your MTA using the right smtp server for each of your outgoing
mail addresses?
Is mail getting stuck in a queue somewhere and you'd never know
unless you poked around in your logs?
...etc, etc.
2. Emacs can store SMTP authentication credentials in an encrypted file,
instead of leaving them sitting in plaintext on the disk (I know that
some MTAs can store them as salted and hashed values after which you
can delete the plaintext original, but Emacs with authinfo.gpg is
even better).
3. Fairly tuneable behavior as far as TLS usage. Emacs unfortunately has
nasty "fail open" behavior as a TLS client per default, and there are
a couple of bug reports open about this, but it is possible to tune
it to implement a "Trust on First Use" or certificate pinning scheme,
which will "fail closed" if an unfamiliar certificate is seen
(similar to the behavior of openssh when seeing a new host). See
https://blogs.fsfe.org/jens.lechtenboerger/2014/03/23/certificate-pinning-for-gnu-emacs/
for an example.
The cons are:
1. Delivery through smtpmail.el is synchronous, blocks your Emacs, and
can be slow. Normally when using the /usr/sbin/sendmail binary on a
*nix system, you are only copying standard output to a queue file,
and delivery happens separately in the background when the mailserver
flushes the queue, so this can be faster (and more importantly feels
faster because you aren't sitting there waiting for your Emacs to
return control to you :-) ). John Wiegley's async.el
library comes with an example which works around the smtpmail
blocking problem:
https://github.com/jwiegley/emacs-async
but because that library relies on using a second Emacs instance to
do the background work, there can be issues with error reporting to
the "master" Emacs, and getting this to work with encrypted auth
credentials is pretty painful.
2. There is no easy recipe built into Gnus and smtpmail.el for the very
common modern case of having several mail identities and needing to
use a different outgoing smtp server for each. For that you need to
figure out (info "(gnus) Posting Styles") and (info "(message) Mail
Variables") and the care and feeding of the "X-Message-SMTP-Method"
header, or else use an addon library like
http://www.emacswiki.org/emacs/GnusAlias
to make it easier to switch ougoing servers. Most MTAs have some
example configuration for the "sender dependent smarthost" problem
and it just works transparently after you set it up. Or people use a
special tiny remote-client-only MTA like msmtp, which handles this
multiple-outgoing-servers case brilliantly using just the -f flag to
/usr/sbin/sendmail.
next prev parent reply other threads:[~2014-11-02 23:55 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-17 16:13 Harry Putnam
2014-10-17 16:36 ` Filipp Gunbin
2014-10-17 21:37 ` Harry Putnam
2014-10-18 0:37 ` Filipp Gunbin
2014-10-18 11:56 ` Filipp Gunbin
2014-11-01 18:35 ` Harry Putnam
2014-11-01 19:02 ` W. Greenhouse
2014-11-02 0:46 ` Harry Putnam
2014-11-02 23:55 ` W. Greenhouse [this message]
2014-11-03 16:59 ` Harry Putnam
2014-10-18 14:10 ` Dave Goldberg
2014-11-01 18:24 ` Harry Putnam
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878ujtkvj1.fsf@motoko.kusanagi \
--to=wgreenhouse-sgozh3hwpm2stnjn9+bgxg@public.gmane.org \
--cc=ding-smP1P7uqpqc@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).