Rationale for this change?

Rationale for this change?

[David Kastrup]

2005-12-05  Ralf Angeli  <angeli@iwi.uni-sb.de>

	* mail/smtpmail.el (smtpmail-try-auth-methods):
	Send credentials together with "AUTH PLAIN" command.

I have not seen this discussed on the list, and it feels to me that
this defeats system administrators who disable "AUTH PLAIN" because
they consider the access path to the mail server under their
administration unsafe for plain text transfers.  While the
authentication is refused, the authentication data itself is still
sent through the network after this change, making the refusal of
"AUTH PLAIN" ineffective for avoiding ill consequences of snoopable
connections.

Could you shed any light on what problem this change is intended to
fix?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Rationale for this change?

[Ralf Angeli]

* David Kastrup (2005-12-28) writes:

> 2005-12-05  Ralf Angeli  <angeli@iwi.uni-sb.de>
>
> 	* mail/smtpmail.el (smtpmail-try-auth-methods):
> 	Send credentials together with "AUTH PLAIN" command.
[...]
> Could you shed any light on what problem this change is intended to
> fix?

<URL:http://mid.gmane.org/E1EjMA3-0003z2-Fu@iwi191.iwi.uni-sb.de>

-- 
Ralf

Re: Rationale for this change?

[Bill Wohler]

David Kastrup <dak@gnu.org> writes:

> Simon Josefsson <jas@extundo.com> writes:
>
>> David Kastrup <dak@gnu.org> writes:
>>
>>> 2005-12-05  Ralf Angeli  <angeli@iwi.uni-sb.de>
>>>
>>> 	* mail/smtpmail.el (smtpmail-try-auth-methods):
>>> 	Send credentials together with "AUTH PLAIN" command.
>>>
>>> Could you shed any light on what problem this change is intended to
>>> fix?
>>
>> The AUTH PLAIN command is not sent if the server did not advertise
>> support for AUTH PLAIN.  See RFC 2554.  The earlier behavior violated
>> a SHOULD in RFC 2222 § 5.1.
>>
>> So security-wise, it is not worse than before.
>
> Ah, ok.  I think rationales like that should be mentioned in the
> ChangeLog.  Even if just as "(RFC 2222 § 5.1)".

Agreed.

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.

Re: Rationale for this change?

[Ralf Angeli]

[Sorry if this shows up twice but the first message sent yesterday
doesn't seem to have reached the list.]

* David Kastrup (2005-12-28) writes:

> 2005-12-05  Ralf Angeli  <angeli@iwi.uni-sb.de>
>
>       * mail/smtpmail.el (smtpmail-try-auth-methods):
>       Send credentials together with "AUTH PLAIN" command.
>
> I have not seen this discussed on the list, and it feels to me that
> this defeats system administrators who disable "AUTH PLAIN" because
> they consider the access path to the mail server under their
> administration unsafe for plain text transfers.  While the
> authentication is refused, the authentication data itself is still
> sent through the network after this change, making the refusal of
> "AUTH PLAIN" ineffective for avoiding ill consequences of snoopable
> connections.

As far as I can see sending an "AUTH PLAIN" string is only tried by
smtpmail.el if the server advertises it as being supported.

> Could you shed any light on what problem this change is intended to
> fix?

See my message to emacs-pretest-bug from 2005-12-05 with the subject
"smtpmail.el: PLAIN authentication fails".  Or on the web:
<URL:http://mid.gmane.org/E1EjMA3-0003z2-Fu@iwi191.iwi.uni-sb.de>

-- 
Ralf

Re: Rationale for this change?

[Simon Josefsson]

David Kastrup <dak@gnu.org> writes:

> 2005-12-05  Ralf Angeli  <angeli@iwi.uni-sb.de>
>
> 	* mail/smtpmail.el (smtpmail-try-auth-methods):
> 	Send credentials together with "AUTH PLAIN" command.
>
> I have not seen this discussed on the list, and it feels to me that
> this defeats system administrators who disable "AUTH PLAIN" because
> they consider the access path to the mail server under their
> administration unsafe for plain text transfers.  While the
> authentication is refused, the authentication data itself is still
> sent through the network after this change, making the refusal of
> "AUTH PLAIN" ineffective for avoiding ill consequences of snoopable
> connections.
>
> Could you shed any light on what problem this change is intended to
> fix?

The AUTH PLAIN command is not sent if the server did not advertise
support for AUTH PLAIN.  See RFC 2554.  The earlier behavior violated
a SHOULD in RFC 2222 § 5.1.

So security-wise, it is not worse than before.

Of course, AUTH PLAIN can only be used securely under a TLS session,
but there are still servers out there that doesn't support TLS.  It is
possible to use AUTH PLAIN under TLS, but disabling AUTH PLAIN without
TLS is unrealistic.

Re: Rationale for this change?

[David Kastrup]

Simon Josefsson <jas@extundo.com> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> 2005-12-05  Ralf Angeli  <angeli@iwi.uni-sb.de>
>>
>> 	* mail/smtpmail.el (smtpmail-try-auth-methods):
>> 	Send credentials together with "AUTH PLAIN" command.
>>
>> Could you shed any light on what problem this change is intended to
>> fix?
>
> The AUTH PLAIN command is not sent if the server did not advertise
> support for AUTH PLAIN.  See RFC 2554.  The earlier behavior violated
> a SHOULD in RFC 2222 § 5.1.
>
> So security-wise, it is not worse than before.

Ah, ok.  I think rationales like that should be mentioned in the
ChangeLog.  Even if just as "(RFC 2222 § 5.1)".

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Rationale for this change?

[Stefan Monnier]

> Ah, ok.  I think rationales like that should be mentioned in the
> ChangeLog.  Even if just as "(RFC 2222 § 5.1)".

Often comments in the code are even better than in the ChangeLog.


        Stefan

Re: Rationale for this change?

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Ah, ok.  I think rationales like that should be mentioned in the
>> ChangeLog.  Even if just as "(RFC 2222 § 5.1)".
>
> Often comments in the code are even better than in the ChangeLog.

It is sort of pointless to talk about which of two things would be
better if one does not rule out the other.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Rationale for this change?

[Richard M. Stallman]

    Ah, ok.  I think rationales like that should be mentioned in the
    ChangeLog.

Not in the ChangeLog.  They should be explained in comments in the code.

Re: Rationale for this change?

[Simon Josefsson]

David Kastrup <dak@gnu.org> writes:

> Simon Josefsson <jas@extundo.com> writes:
>
>> David Kastrup <dak@gnu.org> writes:
>>
>>> 2005-12-05  Ralf Angeli  <angeli@iwi.uni-sb.de>
>>>
>>> 	* mail/smtpmail.el (smtpmail-try-auth-methods):
>>> 	Send credentials together with "AUTH PLAIN" command.
>>>
>>> Could you shed any light on what problem this change is intended to
>>> fix?
>>
>> The AUTH PLAIN command is not sent if the server did not advertise
>> support for AUTH PLAIN.  See RFC 2554.  The earlier behavior violated
>> a SHOULD in RFC 2222 § 5.1.
>>
>> So security-wise, it is not worse than before.
>
> Ah, ok.  I think rationales like that should be mentioned in the
> ChangeLog.  Even if just as "(RFC 2222 § 5.1)".

I have added the following comment in the source code:

	;; We used to send an empty initial request, and wait for an
	;; empty response, and then send the password, but this
	;; violate a SHOULD in RFC 2222 paragraph 5.1.  Note that this
	;; is not sent if the server did not advertise AUTH PLAIN in
	;; the EHLO response.  See RFC 2554 for more info.

Thanks!