Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 24 Mar 2013 09:50:15 -0700
From:      Waitman Gobble <>
To:        Doug Hardie <>
Cc:        " List" <>
Subject:   Re: Client Authentication
Message-ID:  <>
In-Reply-To: <>
References:  <> <> <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
On Sun, Mar 24, 2013 at 1:25 AM, Doug Hardie <> wrote:

> On 24 March 2013, at 01:10, Waitman Gobble <> wrote:
> >
> >
> > You might consider disabling external smtp auth service and using ssh
> tunnel to server to connect to mail. Also provide web based convenience
> service.
> I am not convinced that a ssh tunnel is going to be easy for my users.  We
> do provide a web based mail client, but I wouldn't describe it as
> convenient.  I find it a pain in the neck, but so many users requested it
> that we provide it.  It is password authenticated but so slow it will never
> be attacked with password guessing.

One idea is to run a different server process on 25 which does not do SMTP
AUTH,, then run SMTP AUTH on 465 or 587. I don't really see a reason to
advertise SMTP AUTH on 25, for some reason all mail servers seem to do AUTH
on all ports or none. Maybe there is a way to configure SMTP AUTH only on
certain ports, one way I can think of is to run two processes with two

If some people are specifically attacking your service this may not be
optimal, but if it's script kiddies scanning servers on port 25 this might
discourage them.

Another thought is to modify the SMTP server to allow one or two failed
attempts then lock the account. IRL people set up their password into their
email program and don't type it in all the time, or in the case of web mail
they make their browser remember it. There isn't a good reason I can think
of to allow 100 failed SMTP AUTH attempts. This concept would have to be
tweaked a bit to balance customer service demand. You could also use the
age of the account to determine the number of failed attempts, newer
accounts might get 10 failed attempts, for example.

Or you could disable SMTP auth altogether and make a little program that
sets up a tunnel. Here's an ssh library that's BSD licensed

I think you can decide how much user intervention is needed for port
forwarding. IT could be something like the user has to have the service
installed on their machine, or it's a 'click for email' type thing. A
little program that sets up the tunnel behind the scenes. It takes a day or
two of front end programming but might be a good solution that works on
unix/mac/linux/ms machines. You can have your SMTP AUTH service listening
only on localhost. Handheld devices might become a challenge.

> >
> > It might be interesting to encrypt mail to the user's cloud service that
> operates in a gpg zone. I think this operation could be mostly transparent
> to the user, so kids and granpamas can use it without concern.
> This one I don't understand.  Can you provide pointers to this type of
> service?

Sorry I don't have any pointers, it was an idea last night. The concept is
that users have 'cloud' accounts, email is encrypted to their account,
perhaps (off the top of my head) in a fashion similar to the way friendica
works.(it's not working with cloud systems, but it encrypts information to
individual users, this could be analyzed for ideas for a cloud based
system). This kind of solution might take a week of programming to set up,
so it's more work on the front end.

If you have some archival requirement or need to parse/key or otherwise
analyze messages, in that scenario you would have to copy the message I

Waitman Gobble
San Jose California USA

Want to link to this message? Use this URL: <>