On Apr 17, 2008, at 02:30, Veit Zimmermann wrote:
> May I summarize. I have three options:
>
> 1. Continue to use "high level commands" (Open) and abort and tell the
> user, if the server does not support authentication.
>
> 2. Offer an option to use no authentication.
>
> 3. Chang to more basic
May I summarize. I have three options:
1. Continue to use "high level commands" (Open) and abort and tell the
user, if the server does not support authentication.
2. Offer an option to use no authentication.
3. Chang to more basic functions and switch to no authentication in case
of none avail
DZ-Jay wrote:
> I think we are agreeing there
Yes, completely.
> I agree. So perhaps the best solution for Veit's problem is to not
> use the "highest-level" method (the one that connects, authenticates
> and does all at once), so that he has time to not set the password (if
> that's what he
Arno Garrels wrote:
> Huch, I am Arno? I said that an attempt to send the mail even though
> authentication failed were an easy task from user code.
> Also after the EHLO-response has been received property
> AuthTypesSupported holds a list of auth-types supported by the *server.
> If that list
DZ-Jay wrote:
> Arno Garrels wrote:
>> I think it should since sometimes mail server do not publish all
>> available extensions in the EHLO response. So even if there's no
>> AUTH found in the list TSmtpCli stupidly does a trial and error.
>> This procedure has been suggested by Jake Traynham.
>> I
Arno Garrels wrote:
> I think it should since sometimes mail server do not publish all
> available extensions in the EHLO response. So even if there's no
> AUTH found in the list TSmtpCli stupidly does a trial and error.
> This procedure has been suggested by Jake Traynham.
> It doesn't hurt anyway
Veit Zimmermann wrote:
> Depending on if the user supplies a password or not I set it to one of
> these values. It was on smtpAuthAutoSelect, which seems to trigger the
> "->AUTH CRAM-MD5" request. So is this a bug of TSmtpCli?
smtpAuthAutoSelect tries to find the most secure authentication metho
> Depending on if the user supplies a password or not I set it to one
> of these values. It was on smtpAuthAutoSelect, which seems to
> trigger the "->AUTH CRAM-MD5" request. So is this a bug of
> TSmtpCli? Should it send an AUTH request, if the command is not on
> the list? What is the default
> Depending on if the user supplies a password or not I set it to one of
> these values. It was on smtpAuthAutoSelect, which seems to trigger the
> "->AUTH CRAM-MD5" request. So is this a bug of TSmtpCli? Should it send
> an AUTH request, if the command is not on the list? What is the default
>
Thanks Angus and DZ-Jay also!
Angus Robertson - Magenta Systems Ltd wrote:
>> I'm a little bit at a loss at the moment. I have the following log
>> when trying to open a connection to an SMTP server:
>>
>> <-220 relay.infotn.it - Server ESMTP (Sun Java System Messaging
>> Server 6.2-6.01 (built
> I'm a little bit at a loss at the moment. I have the following log
> when trying to open a connection to an SMTP server:
>
> <-220 relay.infotn.it - Server ESMTP (Sun Java System Messaging
> Server 6.2-6.01 (built Apr 3 2006))
> ->SMTP session connected, error #0
> ->EHLO GPS_Plus
> <-250-rela
Veit Zimmermann wrote:
> ->EHLO GPS_Plus
> <-250-relay.infotn.it
> <-250-8BITMIME
> <-250-PIPELINING
> <-250-DSN
> <-250-ENHANCEDSTATUSCODES
> <-250-HELP
> <-250-XLOOP 887A9C2E9DC36F355DA1AF23F4FAA02
> <-250-ETRN
> <-250-N0-SOLICITING
> <-250 SIZE 0
This is the list of extended commands supported
I'm a little bit at a loss at the moment. I have the following log when
trying to open a connection to an SMTP server:
<-220 relay.infotn.it - Server ESMTP (Sun Java System Messaging Server
6.2-6.01 (built Apr 3 2006))
->SMTP session connected, error #0
->EHLO GPS_Plus
<-250-relay.infotn.it
<-25
13 matches
Mail list logo
