Re: [exim] before we turn on SMTP authentication...

On Mon, 13 Jun 2005, Frank DeChellis wrote:

> We're using Exim 4.44 and are ready to implement SMTP authentication.

I'm speaking for our departmental/faculty mail in this regard (not the
central mail system). You'd need to translate this into your own
situation somehow.

At the present time, we require *remote* users to authenticate
themselves via secure route (587, or 465 for the Billware weenies).
Any of our users attempting to submit from elsewhere to our mailer via
port 25 would be treated like any other remote MTA i.e would most
likely be blocked on the basis of an anti-spam blacklisting.

Authentication is not currently required for users who are on campus
(determined by their source IP, basically).

> Before we do, did any of you run into mail clients that DO NOT
> support SMTP authentication? What was tyour solution around that?

Since the remote authenticated submission was an additional service,
rather than substituting for anything that was there before, we didn't
have much difficulty with it. If/when we start demanding
authentication for on-campus submission I'd expect there to be more
problems, but chiefly because our kind of user will *insist* on "doing
their own thing" rather than taking the standard offering, but aren't
really capable of following the instructions they are given. Then
they complain to their friends "it does not work", which libel
occasionally reaches us, but they refuse to reveal what they're trying
and what symptoms they're getting. Frustrating, really.

Mind you, the criticism of "doing our own thing" could be levelled at
us too, though I try my best to fight against it - I usually get
overruled by manglement...

Solutions that we'd be likely to offer to a user in that position
would be, I think, in no particular order:

* use an ssh client to log in to something you have access to on
campus, and run a mail client there.

* use the campus VPN (so you appear to be on-campus anyway, no matter
where you are)

* if all else fails, use our web/mail interface (which at the moment
is squirrelmail). But this, being stateless, results in much greater
load on our servers, so we try to discourage it except as a last
resort.

At one time we might have recommended ssh tunnelling, which certainly
works when it's set up properly: but explaining to users how to set it
up and use it proved to be so complicated and result in so much
support effort that we abandoned it as a solution.

hope this is useful