[25297] in Athena Bugs
Re: Emacs and SMTP Authentication
daemon@ATHENA.MIT.EDU (Tom Cavin)
Tue Nov 4 13:09:24 2003
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16295.60202.583910.417456@lap1-wccf.mit.edu>
Date: Tue, 4 Nov 2003 13:08:42 -0500
From: Tom Cavin <cavin@mit.edu>
To: Greg Hudson <ghudson@mit.edu>
In-Reply-To: <1067964232.29272.134.camel@error-messages.mit.edu>
cc: Tom Cavin <cavin@mit.edu>
cc: Athena Bugs list <bugs@mit.edu>
Errors-To: bugs-bounces@mit.edu
Hi Greg,
Greg Hudson writes:
> On Tue, 2003-11-04 at 10:48, Tom Cavin wrote:
> > Please correct me if I'm wrong, but I thought we were seeing more and more
> > sites blocking traffic from random *.mit.edu hosts in an effort to reduce
> > spam.
>
> To some extent yes, but how will SMTP authentication help there? You
> can't authenticate to another domain's mail servers (there's no basis
> for authentication), and outgoing.mit.edu is just as much of a *.mit.edu
> host as any other.
If I remember the prediction correctly, according to Jeff Schiller we are
likely to have some of the big players (AOL, et. al.) ask for a limited
number of designanted mail servers which they would whitelist, and they
would blacklist everything else. Presumably, outgoing would be on the
whitelist. The condition for the whitelist entry would probably include
some form of authentication to reduce the spam.
> > If that's the case, there may be some need to immediately bounce
> > mail back that can not be authenticated instead of holding it in a local
> > queue.
>
> We found it difficult to arrange that with sendmail. However, if direct
> delivery fails, you'll get a bounce message.
It may be worth setting the timeout for the "mail delayed, will keep
trying, no user action needed" message to a very short period. It won't
help with the authentication, but it will let users know there has been a
delay. The only potential down-side would be if the "delayed" message
causes its own mail spike. (That could be a significant problem, but it
would depend on the numbers.)
> > One of the reasons I'm asking about Emacs and the smtpmail.el file is that
> > it does its own SMTP submission and queing in user space, and will
> > therefore be able to try to authenticate on later attempts.
>
> Does it actually have queuing, or does it just tell the user about
> failures and punt?
I haven't run it yet, but since the current smtpmail.el file includes:
(defcustom smtpmail-queue-dir "~/Mail/queued-mail/"
"*Directory where `smtpmail.el' stores queued mail."
:type 'directory
:group 'smtpmail)
I would hope that it actually does queue the mail and can therefore attempt
to retry later.
> > Is there an update scheduled for Athena's Emacs lisp code?
>
> We normally update packages like emacs during a full release, but I
> can't imagine there's an upstream emacs release with either SSL or
> GSSAPI capability in the elisp code; crypto and elisp don't generally
> mix. Do you have information to the contrary?
I don't have any real info to the contrary except insofar as I currently
get my mail in Emacs using IMAP-SSL with stunnel from the crypto locker,
and use mailcrypt / GPG when needed. I hadn't realized there was a problem
with SSL or GSSAPI in elisp, but then I don't know a whole lot about the
Emacs internals or packages.
--Tom
_______________________________________________
Bugs@mit.edu
http://mailman.mit.edu/mailman/listinfo/bugs
