Sam Varshavchik wrote:
> Aidas Kasparas writes:
>
>> I do not have arguments why courier should not fallback in 454 cases
>> [remember "be liberal at what you accept" internet principle?].
>
> Because any 4xx SMTP error code means exactly that: "try again later",
> not "try something else entirely, which is less secure".
That is a simplification. In RFC 2821 par 4.2.1 I only find "the action
may be requested again" and
<...>can be successful if repeated
without any change in command form or in properties of the sender
or receiver (that is, the command is repeated identically and the
receiver does not put up a new implementation.)"
I found no "command MUST/SHOULD be repeated in exactly the same way".
Also, I did not find implementation banned from trying different ways to
achieve the same result (like trying different MX). So, "try again
later" is only for the case when no other option exist. If I missed
something, please point this to me.
About security let's read RFC 2487 par 7:
A man-in-the-middle attack can be launched by deleting the "250
STARTTLS" response from the server. This would cause the client not
to try to start a TLS session. An SMTP client can protect against
this attack by recording the fact that a particular SMTP server
offers TLS during one session and generating an alarm if it does not
appear in the EHLO response for a later session. The lack of TLS
during a session SHOULD NOT result in the bouncing of email, although
it could result in delayed processing.
So, STARTTLS is not foolproof and therefore one MUST NOT relay on
STARTTLS for security or privacy (unless he used SECURITY ESMTP
extention while submitting message or have configured administratively
to require STARTTLS for particular destination).
Therefore, I would agree that fallback to plain ESMT from 354 is
"slightly less private" but no "less secure". But, we MUST NOT relay on
that privacy which STARTTLS offers, therefore I see no problem doing
fallback (with exception when STARTTLS is explicitly requested).
--
Aidas Kasparas
IT administrator
GM Consult Group, UAB
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
courier-users mailing list
[email protected]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
