Hello

Thank you very much for responses. After my message, I have found a simple mail server which does not provide any SSL or Authentication support. I sent email to that server instantly so it seems like there is nothing wrong with my smtp module.

> That is in the payload that is sent to the server _after_ that slow 354
> response, right?

Yes that's right. I start sending actualy data after 354 response.

I have checked the spam options of the server but till now I didnt find any solution or problem related to these options. But I will keep looking on it.

Regarding the SMTP logs of server, they onyl provide information such as if the mail is delivered or not, what kind of options are used during delivery etc. and I dont receive any error codes related to my problem. But as I said I will keep looking on the problem and will inform the mail group later. Maybe it will be helpful for other users like me in the future.

P.S: I was receiving mail list messages in a bundle digest. That's why I respond a bit late, sorry. I changed my settings so I have started receiving answers instantly. Thank you again.

Nazim

> From: curl-library-request_at_cool.haxx.se
> Subject: curl-library Digest, Vol 74, Issue 33
> To: curl-library_at_cool.haxx.se
> Date: Tue, 18 Oct 2011 19:56:24 +0200
>
> Send curl-library mailing list submissions to
> curl-library_at_cool.haxx.se
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://cool.haxx.se/cgi-bin/mailman/listinfo/curl-library
> or, via email, send a message with subject or body 'help' to
> curl-library-request_at_cool.haxx.se
>
> You can reach the person managing the list at
> curl-library-owner_at_cool.haxx.se
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of curl-library digest..."
>
>
> Today's Topics:
>
> 1. SMTP Performance of cUrl (Nazim Oztahtaci)
> 2. Re: SMTP Performance of cUrl (Daniel Stenberg)
> 3. RE: SMTP Performance of cUrl (Steve Holme)
> 4. RE: SMTP Performance of cUrl (Patrick Monnerat)
> 5. Re: sftp and buffersize (Daniel Stenberg)
> 6. Re: sftp and buffersize (Jonas Schnelli)
> 7. Re: Error in select().. returns -1 (ketrio juki)
> 8. Re: Error in select().. returns -1 (Daniel Stenberg)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 18 Oct 2011 10:32:12 +0000
> From: Nazim Oztahtaci <nazim_oztahtaci_at_hotmail.com>
> To: <curl-library_at_cool.haxx.se>
> Subject: SMTP Performance of cUrl
> Message-ID: <SNT121-W30948A4799AC9266C62FB596E50_at_phx.gbl>
> Content-Type: text/plain; charset="windows-1254"
>
>
> Hello again,
>
> As I have mentioned previously Im working on an smtp module in C. I have provided SSL support and am able to send encrypted emails over TLS on port 587. I have tested different email servers but some of them had problems with SSL certificates so Im using SmarterMail program. The problem is when I send email from the module, it takes around 4-5 seconds to receive "354 Start mail input; end with <CRLF>.<CRLF>" and state goes from RCTP to DATA. My question is if this is a normal time flow? As I have checked previous messages on the mail group, people had speed problems about POST but they were related to their server or network configurations. Am I facing a similar problem or is this a usual case for cUrl?
>
> P.S: I use a simple MIME header and an attachment with 2Kb in the mail.
>
> Best regards,
>
> Nazim
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://cool.haxx.se/pipermail/curl-library/attachments/20111018/1625750e/attachment-0001.html>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 18 Oct 2011 13:19:06 +0200 (CEST)
> From: Daniel Stenberg <daniel_at_haxx.se>
> To: libcurl development <curl-library_at_cool.haxx.se>
> Subject: Re: SMTP Performance of cUrl
> Message-ID: <alpine.DEB.2.00.1110181315370.24124_at_tvnag.unkk.fr>
> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
>
> On Tue, 18 Oct 2011, Nazim Oztahtaci wrote:
>
> > The problem is when I send email from the module, it takes around 4-5
> > seconds to receive "354 Start mail input; end with <CRLF>.<CRLF>" and state
> > goes from RCTP to DATA. My question is if this is a normal time flow?
>
> I don't think it is normal - a server should be able to respond more or less
> instantly. But since you wait for the server's response it is nothing libcurl
> can do anything about.
>
> > P.S: I use a simple MIME header and an attachment with 2Kb in the mail.
>
> That is in the payload that is sent to the server _after_ that slow 354
> response, right?
>
> --
>
> / daniel.haxx.se
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 18 Oct 2011 12:31:11 +0100
> From: Steve Holme <steve_holme_at_hotmail.com>
> To: "'libcurl development'" <curl-library_at_cool.haxx.se>
> Subject: RE: SMTP Performance of cUrl
> Message-ID: <BAY164-ds205B8E90F718B77BC9477D82E50_at_phx.gbl>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi Nazim,
>
> > The problem is when I send email from the module, it takes around 4-5
> > seconds to receive "354 Start mail input; end with <CRLF>.<CRLF>" and
> state
> > goes from RCTP to DATA. My question is if this is a normal time flow?
>
> I've not noticed this with Exchange server myself.
>
> > As I have checked previous messages on the mail group, people had speed
> > problems about POST but they were related to their server or network
> > configurations. Am I facing a similar problem or is this a usual case for
> cUrl?
>
> Have you tried running the command line version of Curl to see if it behaves
> the same as your module?
>
> Additionally, does SmarterMail provide any kind of logging, so you can see
> the mail flow from the server's prospective?
>
> > P.S: I use a simple MIME header and an attachment with 2Kb in the mail.
>
> That is in the mail input so after your delay. I do this type of payload
> myself for file attachments but I also have multipart/alternative sub
> messages for html as well ;-)
>
> Kind Regards
>
> Steve
>
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 18 Oct 2011 13:45:57 +0200
> From: "Patrick Monnerat" <Patrick.Monnerat_at_datasphere.ch>
> To: "libcurl development" <curl-library_at_cool.haxx.se>
> Subject: RE: SMTP Performance of cUrl
> Message-ID: <AB5E58B87EB73C46A38073D8F459F113D9F687_at_dataspheresrv01>
> Content-Type: text/plain; charset="us-ascii"
>
>
> Daniel Stenberg wrote:
> >> The problem is when I send email from the module, it takes around 4-5
>
> >> seconds to receive "354 Start mail input; end with <CRLF>.<CRLF>" and
>
> >> state goes from RCTP to DATA. My question is if this is a normal time
> flow?
>
> > I don't think it is normal - a server should be able to respond more
> or less instantly. But since you wait for the server's response it is
> nothing libcurl can do anything about.
>
> In fact it may be normal: by configuration, some SMTP servers wait some
> seconds after connect before sending the connect answer and discard
> everything from a client beginning to "talk" before this initial reply.
> This is a very efficient anti-spam disposition :-) See
> http://acme.com/mail_filtering/sendmail_config_frameset.html.
>
> For the current problem, I would check the SMTP dialog timeline from the
> connection, and perform some tests against another server...
>
> Patrick
>
>
>
> ------------------------------
>
> Message: 5
> Date: Tue, 18 Oct 2011 14:07:04 +0200 (CEST)
> From: Daniel Stenberg <daniel_at_haxx.se>
> To: libcurl development <curl-library_at_cool.haxx.se>
> Subject: Re: sftp and buffersize
> Message-ID: <alpine.DEB.2.00.1110181359140.24124_at_tvnag.unkk.fr>
> Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; FORMAT=flowed
>
> On Mon, 17 Oct 2011, Jonas Schnelli wrote:
>
> > Is the CURL_MAX_WRITE_SIZE anyhow configurable? (you already said no, aren't
> > you? :) )
>
> No it isn't.
>
> > Is it difficult to make the CURL_MAX_WRITE_SIZE anyhow configurable?
>
> Nah. Right now SessionHandle->uploadbuffer is a fixed array with a static
> size, but it should be fairly easy to modify that to an allocated buffer for
> which the size would be configurable with a setopt() option.
>
> > I would then try to change the CURL_MAX_WRITE_SIZE (of let's say the SFTP
> > buffer size) dependent on the historical speed of the nework (or maybe also
> > configurable by the enduser: like "select your internet connection type:").
>
> Perhaps we should rather just change the size internally at our own choice
> depending on internally known details? After all, libcurl knows that SFTP will
> benefit from huge buffers while an application cannot possibly know this. The
> question is then perhaps only what a "large buffer" should be and perhaps have
> that option set by the application?
>
> --
>
> / daniel.haxx.se
>
>
> ------------------------------
>
> Message: 6
> Date: Tue, 18 Oct 2011 14:14:58 +0200
> From: Jonas Schnelli <jonas.schnelli_at_include7.ch>
> To: libcurl development <curl-library_at_cool.haxx.se>
> Subject: Re: sftp and buffersize
> Message-ID: <CCD096F6-B9DE-4AF6-9FC4-A3C1F096840B_at_include7.ch>
> Content-Type: text/plain; charset="us-ascii"
>
>
>
> > On Mon, 17 Oct 2011, Jonas Schnelli wrote:
> >
> >> Is the CURL_MAX_WRITE_SIZE anyhow configurable? (you already said no, aren't you? :) )
> >
> > No it isn't.
> >
> >> Is it difficult to make the CURL_MAX_WRITE_SIZE anyhow configurable?
> >
> > Nah. Right now SessionHandle->uploadbuffer is a fixed array with a static size, but it should be fairly easy to modify that to an allocated buffer for which the size would be configurable with a setopt() option.
> >
> >> I would then try to change the CURL_MAX_WRITE_SIZE (of let's say the SFTP buffer size) dependent on the historical speed of the nework (or maybe also configurable by the enduser: like "select your internet connection type:").
> >
> > Perhaps we should rather just change the size internally at our own choice depending on internally known details? After all, libcurl knows that SFTP will benefit from huge buffers while an application cannot possibly know this. The question is then perhaps only what a "large buffer" should be and perhaps have that option set by the application?
> >
>
> Okay. Let me try something (as soon as the sftp-userstory is on the top).
> As soon as i have a patchset we can discuss that.
>
> Thanks
>
>
> > --
> >
> > / daniel.haxx.se
> > -------------------------------------------------------------------
> > List admin: http://cool.haxx.se/list/listinfo/curl-library
> > Etiquette: http://curl.haxx.se/mail/etiquette.html
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://cool.haxx.se/pipermail/curl-library/attachments/20111018/714da080/attachment-0001.html>
>
> ------------------------------
>
> Message: 7
> Date: Tue, 18 Oct 2011 13:25:09 +0100 (BST)
> From: ketrio juki <ketriop_at_yahoo.it>
> To: libcurl development <curl-library_at_cool.haxx.se>
> Subject: Re: Error in select().. returns -1
> Message-ID:
> <1318940709.65001.YahooMailNeo_at_web29520.mail.ird.yahoo.com>
> Content-Type: text/plain; charset="utf-8"
>
>
> >> Sorry for the top posting Daniel.. so doing something like this can solve the problem?
>
> >Yes. But your solution busy-loops like crazy and I would never advice anyone to do that. If you read the man page again I advocate unconditionally _waiting_ a short while before continuing for this case.
>
> So according to you which could be a good solution? Insert a sleep like in example "10-at-a-time.c"? Any other suggestions?
> Thanks.
>
> Matt
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://cool.haxx.se/pipermail/curl-library/attachments/20111018/732e04a9/attachment-0001.html>
>
> ------------------------------
>
> Message: 8
> Date: Tue, 18 Oct 2011 19:56:23 +0200 (CEST)
> From: Daniel Stenberg <daniel_at_haxx.se>
> To: libcurl development <curl-library_at_cool.haxx.se>
> Subject: Re: Error in select().. returns -1
> Message-ID: <alpine.DEB.2.00.1110181427160.24124_at_tvnag.unkk.fr>
> Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
>
> On Tue, 18 Oct 2011, ketrio juki wrote:
>
> >> I advocate unconditionally _waiting_ a short while
> >
> > So according to you which could be a good solution? Insert a sleep like in
> > example "10-at-a-time.c"?
>
> Are you suggesting a difference between waiting and sleeping?
>
> --
>
> / daniel.haxx.se
>
>
> ------------------------------
>
> _______________________________________________
> curl-library mailing list
> curl-library_at_cool.haxx.se
> http://cool.haxx.se/cgi-bin/mailman/listinfo/curl-library
>
>
> End of curl-library Digest, Vol 74, Issue 33
> ********************************************
                                               

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2011-10-19