Hi Aidas,
On Wednesday 14 May 2008 20:53:46 Aidas Kasparas wrote:
> Arno wrote:
> > AFAIK it isn't possible in general. But think about it: why should it? If
> > you announce being able do TLS and actually you aren't why should you
> > announce it in the first place? It's up to the receiving server to get it
> > right. Either I do "speak" TLS and announce it, or I can't. In the latter
> > case I can't announce it.
>
> Why do you think it is not possible in general?
I wasn't specific enough. I meant: Not possible with courier in general.
Sorry.
> >From technical point of view, server allways provides ESMTP response to
>
> STARTTLS command. This command can have limited set of reply codes
> {220,501,454}. Only first of them says that TLS negotiation should
> start. So, technically it is possible to distinguish cases.
To be honest, I didn't know that. I haven't read that RFC yet, but I will.
Could you please tell me which one it is? I honestly don't know.
> As to why host should advertise TLS capabilities and later refuse to use
> it. Mis/under-configuration is one (if software detects this in lazy
> way). Lack of resources at the moment of STARTTLS command is another
> (load too high at the moment, TLS-accelerator is full, etc).
I haven't thought about the "load too high"-scenario or any other things that
would qualify a true temporaray error.
> I do not have arguments why courier should not fallback in 454 cases
> [remember "be liberal at what you accept" internet principle?].
True. I have to admit, I'm kinda blended by my own prejudices here. Right now
I've ony met admins:
1. Who don't respond
2. Who respond but WONTFIX
3. Admins who fix the problem, either by creating a cert or turning off
STARTTLS
Until now I honestly haven't seen a server that announces TLS, returns a
temporary error and later accepts STARTTLS.
I've met 2 or 3 admins who were grateful for telling them about their problem,
and they were quite responsive, but that's a minority. Most of them are of
category 1. Few of them are of category 2, and for the most astonishing
reasons. If it weren't so sad, I'd have some good laughs.
But nevertheless, thank you for making me aware of those other problems that
can arise. Haven't thought about them, because it didn't occur to me (yet).
--
Regards,
Arno.
--
Gruß,
Arno.
-------------------------------------------------------------------------
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
