Re: [Exim] Help with SMTP AUTH

Page principale
Supprimer ce message
Répondre à ce message
Auteur: Dave C.
Date:  
À: Tamas TEVESZ
CC: Matt Bernstein, Exim Users
Sujet: Re: [Exim] Help with SMTP AUTH


On Tue, 28 Aug 2001, Tamas TEVESZ wrote:

> On Tue, 28 Aug 2001, Matt Bernstein wrote:
>
>  > ..but it's too late by then! You say (in the clear)
>  >     AUTH PLAIN MiMeHaSh..
>  > ..and the server replies
>  >     503 STARTTLS required before AUTH

>
> the server doesn't have to advertise it's auth-capability unless the
> channel is already secured :) (no, i don't know how (if at all) to do
> that. but it wouldn't be nice...)
>
> otoh - once one does ssl, then why bother with passwords ? use
> certificates then :)


You mean, like Verisign certificates? No thanks.

If you mean locally generated ones, good luck getting clients (the
program kind) to accept them..

I think I'll stick with username/passwords.

I will also note, that, just like with https, the few seconds of
transmission is the LEAST likely point at which something will be
intercepted. Its the back-end storage/transmission of the data that is
far more likely to be a target.

If you have HTTPS, enabled on your server, but then proceed to use
formmail to email CC#'s in the clear to wherever, or if you store it in
a database that isnt properly secured, you gain only the appearance of
security.

If however, you use PGP to encrypt the data as soon as it is received by
the CGI, before doing anything else (and do not store the private key on
that server or anywhere else that isnt locked down), then https, while
making you 'look' more secure, really doesnt add that much..

As far as using TLS with SMTP auth, why bother? Spammers do NOT sit
sniffing SMTP sessions to try and catch username and password pairs to
send spam (and where would they sniff from anyway?) - that would be way
too much work - there are still plenty of open SMTP servers out there,
despite MAPS/RSS/ORBS/etc best efforts. And if some rogue employee at a
backbone network wanted to try and break into your site (unlikely) by
sniffing for SMTP AUTH passwords, they would have to wade through
gigbytes of traffic looking. Poeple just dont do that.

And if you or your clients are transmitting sensitive/confidential
information, you really should be using something like PGP to provide
origin-to-destination security. Encrypting the SMTP session, unless you
also encrypt your mail spool, just gives a false sense of security.