Suggestion: fix email delivery speed with SmarterMail

[Michael Muller]

Once I moved to Railo my email delivery speed for bulk messages generated by my CF code went from near-instantaneous to nearly six hours, or longer. Doing some research shows that it's a problem specific to Railo and SM, and the bandied solution is to install another SMTP server on the app server to hand mail to SM on the other machine.

This seems a bit silly, since (a) installing an SMTP server on the app server negates the efficiencies of having a separate mail server, and (b) it adds a hop to the headers, which can have a negative impact on delivery and acceptance.

I don't have to use SmarterMail, of course, ("Doctor, it hurts when I do this", "Well, don't do that!") but it's what I know, it supports incoming mail, has great filtering and anti-spam and reporting, and a single-domain license is free.

Would that be an easy fix in Lucee, or is it a configuration thing?

Thanks,

Mik

[Martin Schaible]

I'm quite familiary with SmarterMail. I'm using this product since ever. I'm pretty sure, that your configuration of SmarterMail does delay your mailings.First, please check if throttling is disabled for the account, which you use to send the mails.

Cheers

Martin

[Michael Sprague]

Why not use something like Mandrill (mandrillapp.com) to handle your outgoing messages? No SMTP server to install, up to 12,000 emails/month on the free plan, and you get some nice reporting features. 

There's an API to handle everything you need programmatically, and I also used their webhooks to create incoming email accounts that perform certain actions upon received messages.

Great product, worth a look.

Mike

--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/da30d22a-4506-4f77-91f0-49242a4331c1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mark Drew]

Similar to mandrilapp.com there is also https://postmarkapp.com/ that allows you to handle inbound and return emails  (and even still use it as SMTP as well as api) 

But go with the throttling thing first :) 

MD 

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAB1Zp0J6nDZXsF938KUHAdo6Q9bPsAO%2BebkGrJJi1OojiorPcg%40mail.gmail.com.

[Martin Schaible]

btw, the free or payed edition of SmarterMail isn't a bad idea to use as an outgoing SMTP mail server at all. Easy to use, very reliable and uses nearly no resources. The free edition allows to have one mail domain only.

[Michael Muller]

All three throttling settings were set to "none."

[Martin Schaible]

Okay, next: the log files. Check the SMTP log file. Find the position of your first sended mail of your campaign and scroll down. Check for unsual messages and have a look at the timestamps to see how much time was needed to process a mail.

[Michael Muller]

These emails are stuck on the Railo server, not the mail server. Once they hit the mail server they go quickly. While they're on the Railo server, they go out about one per minute, and that only after we tweaked the server.xml file to add ...

<Executor name="tomcatThreadPool" namePrefix="catalina-exec-" maxThreads="150" minSpareThreads="4"/>

... inside <Service name="Catalina">, then added ...

executor="tomcatThreadPool"

... to <Connector port="8009" protocol="AJP/1.3" redirectPort="8443"  />

This got me up to about three per minute.


I'm going through all the Railo logs from a couple days ago when the jam really got bad, and finding nothing that refers to email spooling.

I did find the folders with the *.tsk files. Created a backup folder and cleared them all out. Perhaps this will speed things up. I will test and report.

Mik

[Michael Muller]

Ok. I cleared out the queue and started a fresh bulk mail. It took 45 minutes to send 100 messages. Not really quick enough when you consider I need to crank out up to 50,000 in a day, some days.

On Denny's suggestion, I'm going to look into hmailserver as an internal proxy to see if that speeds things up.

http://swxben.com/setting-up-an-open-smtp-relay-in-an-intranet-with-hmailserver/

That said, I think figuring out why Railo/Lucee doesn't play well with SmarterMail should be a ticket. I'll post it.

[Alex Skinner]

My view is that until you can prove it is specifically a smarter mail issue or one about compatibility with smarter mail that the ticket should be about slow email sending speed.

Can I ask you what you are doing for DNS and how quick the DNS lookups are ?

So if you go to your Railo server and do a DNS lookup whats the time ? It just occurs to me that it might be network related either DNS lookups or security are u using TLS ?

Have you tried temporarily setting up an account with mailgun.com in order to see whether the issue occurs with a mail server not in your environment ?

Thanks

Alex

--

You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/ceed92be-aea9-4d09-a9a2-fb7e31ca0686%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Alex Skinner
Managing Director

Pixl8 Interactive, 3 Tun Yard, Peardon Street, London SW8 3HT, United Kingdom T: +44 [0] 845 260 0726• W: www.pixl8.co.uk• E: in...@pixl8.co.uk

Follow us on: Facebook Twitter LinkedIn

CONFIDENTIAL AND PRIVILEGED - This e-mail and any attachment is intended solely for the addressee, is strictly confidential and may also be subject to legal, professional or other privilege or may be protected by work product immunity or other legal rules. If you are not the addressee please do not read, print, re-transmit, store or act in reliance on it or any attachments. Instead, please email it back to the sender and then immediately permanently delete it. Pixl8 Interactive Ltd Registered in England. Registered number: 04336501. Registered office: 8 Spur Road, Cosham, Portsmouth, Hampshire, PO6 3EB

[Michael Hnat]

Alex, followong your hint, using the IP address instead oft the DNS Name maybe brings some performance.

Best, michi

[Michael Muller]

I have another server, ACF9 (my old server I'm still migrating away from), that has one website that regularly sends out about 24,000+ emails through the same exact mailserver. They are all sent in a timely manner.

I'm using Windows DNS, though I've always entered the IP number for the mail server. And I'm not using TLS.

I just ran two tests using hmailserver. The first sent out four messages nearly instantaneously, though I got an error in the hmailserver logs: "SENT: 535 Authentication failed. Restarting authentication process." So I changed from "Use STARTTLS (optional)" to "None" for authentication (my mail server accepts mail only from specific IP numbers, and requires un/pw authentication). It took 20 minutes to deliver to my Gmail address.

Still noodling...

Mik

[Alex Skinner]

Have you tried relaying through something external to your network like Mailgun.

If on your internal network do you have reverse DNS and SPF records in place ?

Thanks

Alex

--

You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/3c79afb0-86a3-4432-b521-169db114a8fe%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Michael Sprague]

I, too, would recommend a trial run with Mailgun or Mandrill (as I suggested yesterday). If you don't see any improvements with an off-network solution it would seem easier to point at Lucee as the culprit. 

Who knows, you may end up liking said services and find yourself with one less thing to maintain/troubleshoot on your network.

Best,

Mike

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAFrbJ5U8gWF5xHSN7vomLUgaSNdVUQ0%3DaENz7CVJ9n4RR_8LGw%40mail.gmail.com.

[Michael Muller]

On Thursday, February 5, 2015 at 1:57:08 PM UTC-5, Alex Skinner wrote:

Have you tried relaying through something external to your network like Mailgun.

I have not, though I am now using hMailServer on my app server.

If on your internal network do you have reverse DNS and SPF records in place ?

I do. Both.

This is an issue of the app server (Railo) connecting directly, via IP number, to an SMTP mail server to deliver the mail.

Thanks.

[Jordan Michaels]

Hey Michael,

I can confirm that there is an issue specifically with Smartermail & Railo/Lucee... even though using any other mail server or mailing service will work just fine, and even though ACF & Smartermail will work just fine. I have not taken the time, personally, to track down the issue at this point. If you're still researching it, I'd be extremely interested in your findings.

When our technicians looked at it, they were under the impression that it had something to do with how Railo & Smartermail were communicating, because as you noticed the mail messages would sit on the Railo server for quite a while before *finally* being accepted by Smartermail and delivered. What we were going to do was turn on debug-level logging and wade through all that data to try to figure out what was happening. However, once we found the workaround of using hMail, we stopped investigating. I would still very much like to know what's going on there. Lots of folks use Smartermail, and it would be ideal if we had a *real* solution for them, rather than suggesting folks use some other service.

Smartermail works just fine with ACF, why not with Railo/Lucee? I don't know. Good question. I'd like to know why too.

Kind regards,
Jordan Michaels

--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/4a422c01-14b9-4f98-8e4a-f5ba1727d6ed%40googlegroups.com.

[Martin Schaible]

Can i help in any way? I could create some code which spits let's say 50-100 Mails to our SmarterMail-Server. The Logfiles will tell me everything.

[denstar]

The odd thing is that Mik is already using hMailServer as an internal
MTA, proxying to SmarterMail, and he's still seeing the same problem.

Did you guys disable spooling when you started using hMail as a proxy?

Any other configuration changes stick out in your mind? We've got the
threads bumped up, but that didn't help much.

-Den*

[denstar]

Are you seeing the same problem then?

I wrote a cfjavamail extension a long time ago, as there was one odd
thing about how the Railo code at that time was setting something (TLS
or SLL, both were enabled when only one should have been or something,
hard to recall), but I'd be surprised if that hadn't been fixed years ago.

I would have thought DNS or something too, but this seems like something
different.

-Den*

[Martin Schaible]

Are you seeing the same problem then?

I didn't really sent a lot of mail generated by CFML-code so far. But as a SmarterMail-tekkie-guy, this problem caught my interest. 

[Anton]

Hello everyone,

I can confirm the same issue on my server. I am running Windows Server 2008 R2 with SmarterMail 13.2. Sending emails with CF7.0 on the same server was easy and fast. Once I switched to Railo and later to Lucee emails are taking forever to leave. Current speed is about 1 email per second. I used to be able to send 10K emails in under an hour now it takes about 24 hours!  Emails are stuck on the Railo/Lucee side, not on the SmarterMail side. Any suggestions are welcome, otherwise I will have to go back to CF.

Cheers,
Anton

[Andrew Penhorwood]

Has anyone done in-depth logging on this issue.  SmarterMail looks like a nice product, though I only looked over their website.  Can we turn on detailed logging on both sides of the problem, Lucee and Smartermail.  We should be able to see what is happening.  Have you used wireshark to review the connection?  We can solve this issue.

Andrew Penhorwood

[Michael Muller]

If anyone is interested in helping with this issue I can open up my servers via a TeamViewer session and work with you in real time. This would have to wait until Monday or Tuesday, though.

[Andrew Penhorwood]

I am willing to look over log files but my time 8 to 5 belongs to my employer.  I am located in Indiana ( EST ).  If you could capture the network traffic via wireshark then we can review that too.  If you have never used wifeshark before it is fairly easy to capture the packets as they cross the wire.

Andrew Penhorwood

[Martin Schaible]

@Andrew: I could offer you an account for testing on my SmarterMail server. I have access to the logfiles for investigation.
The proble might be: How many mails to send are needed and who are the recepients. I want to avoid getting blacklisted somewhere.

[Andrew Penhorwood]

If possible capturing the packets between Lucee & SmarterMail might be the best course of action.  Can you run wireshark on the Lucee server?  Do you have that level of access?  We should be able to see where the communication issue is happening.  Yes you don't want to be blacklisted, that happened to me many years ago and it was a real pain to fix.

Andrew Penhorwood

[Christian Meis]

I'm reluctant to use wifeshark, as I'm unsure where it would leave me family-wise ;-)

SCNR,
Christian

[Christian Meis]

If that would be of any help I could offer creating target mail addresses on one our mail systems to send to.

I can also take a look at Wireshark files if help is needed.
Just in case someone wants any kind of help here: I'll be out of office next week...

Christian Meis

[Martin Schaible]

My idea is that you can send testmail over my SmarterMail box. I will really help to see, how the log files from SmarterMail looks like. Any delays will be visible and the timestamps too. Unfortunately i can't help with wireshark.

[Andrew Penhorwood]

OK.  I should be able to setup a test tomorrow night.  You can send any information to me at and...@coldbits.com.  I can run wireshark on the connection so we can see all of the packets going and coming.

Andrew Penhorwood

[Andrew Penhorwood]

Running wireshark on the connection was interesting.  The following dumps of the SMTP communications were filtered by using place holders for personal data.

Test:  A loop sending the same email 100 times.  Both servers spooled the messages so the CF page had little to do with the process.  I was watching the packets with wireshark.  ACF sent them out very quickly.  Lucee sent them very slow at about 1 a minute or so.  I finally deleted off the mail task via the Lucee Web Admin.

ACF uses a new TCP connection for each email.  Lucee reusing the TCP connection it appears.  I have the packet captures if someone at Lucee wants to review them.

Adobe ColdFusion & SmarterMail

220 {mail server} Fri, 13 Feb 2015 00:43:13 +0000 UTC SmarterMail Enterprise 12.x

EHLO boaz.local

250-{mail server} Hello [184.170.172.32]

250-SIZE 52428800

250-AUTH LOGIN CRAM-MD5

250-8BITMIME

250 OK

AUTH LOGIN

334 VXNlcm5hbWU6

 {username}

334 UGFzc3dvcmQ6

 {password}

235 Authentication successful

MAIL FROM:< {from} >

250 OK < {from} > Sender ok

RCPT TO:< {to} >

250 OK < {to} > Recipient ok

DATA

354 Start mail input; end with <CRLF>.<CRLF>

Date: Thu, 12 Feb 2015 19:43:16 -0500 (EST)

From:  {from}

To:  {to}

Message-ID: <1762409123.31.1423788196662.JavaMail.JEREMIAH$@{mail server}>

Subject: SmarterMail-ColdFusion 10: {ts '2015-02-12 19:42:26'} | 23

MIME-Version: 1.0

Content-Type: text/plain; charset=UTF-8

Content-Transfer-Encoding: 7bit

X-Mailer: SmarterMail-Testor

the quick brown fox jumped over the lazy dogs.

 Test Message: {ts '2015-02-12 19:42:26'}.

.

250 OK

QUIT

221 Service closing transmission channel

Here is Lucee & SmarterMail's communication:

220 {mail server} Fri, 13 Feb 2015 00:02:49 +0000 UTC SmarterMail Enterprise 12.x

EHLO Jeremiah

250-{mail server} Hello [184.170.172.32]

250-SIZE 52428800

250-AUTH LOGIN CRAM-MD5

250-8BITMIME

250 OK

AUTH LOGIN

334 VXNlcm5hbWU6

 {username}

334 UGFzc3dvcmQ6

 {password}

235 Authentication successful

MAIL FROM:< {from} >

250 OK < {from} > Sender ok

RCPT TO:< {to} >

250 OK < {to} > Recipient ok

DATA

354 Start mail input; end with <CRLF>.<CRLF>

Message-ID: <1773559859.61423785772924.JavaMail.Andrew@Jeremiah>

Date: Thu, 12 Feb 2015 19:02:34 -0500 (EST)

From:  {from}

To:  {to}

Subject: SmarterMail Test: {ts '2015-02-12 19:02:35'} | 1

MIME-Version: 1.0

Content-Type: text/plain; charset=UTF-8

Content-Transfer-Encoding: 7bit

X-Mailer: SmarterMail-Testor

the quick brown fox jumped over the lazy dogs.

 Test Message: {ts '2015-02-12 19:02:35'}.

.

250 OK

NOOP

250 OK

MAIL FROM:< {from} >

250 OK < {from} > Sender ok

RCPT TO:< {to} >

250 OK < {to} > Recipient ok

DATA

354 Start mail input; end with <CRLF>.<CRLF>

Message-ID: <949204990.71423785774068.JavaMail.Andrew@Jeremiah>

Date: Thu, 12 Feb 2015 19:02:53 -0500 (EST)

From:  {from}

To:  {to}

Subject: SmarterMail Test: {ts '2015-02-12 19:02:35'} | 3

MIME-Version: 1.0

Content-Type: text/plain; charset=UTF-8

Content-Transfer-Encoding: 7bit

X-Mailer: SmarterMail-Testor

the quick brown fox jumped over the lazy dogs.

 Test Message: {ts '2015-02-12 19:02:35'}.

.

250 OK

NOOP

250 OK

MAIL FROM:< {from} >

250 OK < {from} > Sender ok

RCPT TO:< {to} >

250 OK < {to} > Recipient ok

DATA

354 Start mail input; end with <CRLF>.<CRLF>

Message-ID: <1977610596.81423785775706.JavaMail.Andrew@Jeremiah>

Date: Thu, 12 Feb 2015 19:02:54 -0500 (EST)

From:  {from}

To:  {to}

Subject: SmarterMail Test: {ts '2015-02-12 19:02:35'} | 2

MIME-Version: 1.0

Content-Type: text/plain; charset=UTF-8

Content-Transfer-Encoding: 7bit

X-Mailer: SmarterMail-Testor

the quick brown fox jumped over the lazy dogs.

 Test Message: {ts '2015-02-12 19:02:35'}.

.

250 OK

NOOP

250 OK

MAIL FROM:< {from} >

250 OK < {from} > Sender ok

RCPT TO:< {to} >

250 OK < {to} > Recipient ok

DATA

354 Start mail input; end with <CRLF>.<CRLF>

Message-ID: <1539161151.91423785782260.JavaMail.Andrew@Jeremiah>

Date: Thu, 12 Feb 2015 19:03:00 -0500 (EST)

From:  {from}

To:  {to}

Subject: SmarterMail Test: {ts '2015-02-12 19:02:35'} | 4

MIME-Version: 1.0

Content-Type: text/plain; charset=UTF-8

Content-Transfer-Encoding: 7bit

X-Mailer: SmarterMail-Testor

the quick brown fox jumped over the lazy dogs.

 Test Message: {ts '2015-02-12 19:02:35'}.

.

250 OK

NOOP

250 OK

MAIL FROM:< {from} >

250 OK < {from} > Sender ok

RCPT TO:< {to} >

250 OK < {to} > Recipient ok

DATA

354 Start mail input; end with <CRLF>.<CRLF>

Message-ID: <1187317698.101423785784895.JavaMail.Andrew@Jeremiah>

Date: Thu, 12 Feb 2015 19:03:02 -0500 (EST)

From:  {from}

To:  {to}

Subject: SmarterMail Test: {ts '2015-02-12 19:02:35'} | 22

MIME-Version: 1.0

Content-Type: text/plain; charset=UTF-8

Content-Transfer-Encoding: 7bit

X-Mailer: SmarterMail-Testor

the quick brown fox jumped over the lazy dogs.

 Test Message: {ts '2015-02-12 19:02:35'}.

[Andrew Penhorwood]

The Lucee - SmarterMail issue appears to be bug / deliberate on SmarterMail's end.  In looking through the packet capture the first NOOP command was acknowledged in 1 second.  Later after more mails were sent the time period between NOOP and response went up to 2 seconds.  There does not appear to be number of messages sent pattern but after each NOOP command the time response increased to 3, 4 and 5 seconds.  At the end of my capture the time interval is up to 20 seconds between NOOP and response.

Since ACF treats each message as a new TCP channel it does not experience this NOOP issue but they do experience the overhead of building a new TCP connection on every message.

Andrew Penhorwood

[Christian Meis]

I don't know SmarterMail - but maybe that's some kind of configurable "mass-mailing-tarpit"? I've seen the strangest configuration options in mail server software in this regard...

Christian

[Jochem van Dieten]

On Sat, Feb 14, 2015 at 4:31 AM, Andrew Penhorwood wrote:

The Lucee - SmarterMail issue appears to be bug / deliberate on SmarterMail's end.  In looking through the packet capture the first NOOP command was acknowledged in 1 second.  Later after more mails were sent the time period between NOOP and response went up to 2 seconds.  There does not appear to be number of messages sent pattern but after each NOOP command the time response increased to 3, 4 and 5 seconds.  At the end of my capture the time interval is up to 20 seconds between NOOP and response.

That is very much a smoking gun pointing to SmarterMail. I think this is the point where all SmarterMail customers should start filing bugs with them.

However, for SmarterMail to fix this issue and get the fix deployed to all installs worldwide might take some time. So it might be prudent to change the code on the Lucee side to work around it as well. What might be the easiest change is to implement the connection reuse not by issueing a NOOP command after each message, but a RSET. Per RFC 2821 section 4.1.1.5 this is effectively the same when used after an end-of-data command. What makes me suspect this might bypass the SmarterMail bug is that that is the way Sendmail and Postfix reuse connections, and I can't imagine SmarterMail would not test their product against them.

Jochem

--

Jochem van Dieten
http://jochem.vandieten.net/

[Michael Offner]

Lucee is reusing the connections for good reasons, doing a new connection for every mail is a horrible overhead.

But if this cause problems with smartermail, we could add a option to the mail server configuration, "do not reuse connections (some mail server cannot handle this ...)"

Micha

--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CABPCP-00OzWikP%2Bt9jaZQ8p9%3DDB3h1OGFOwsBaKFQBt5uoCTzA%40mail.gmail.com.

[Martin Schaible]

we could add a option to the mail server configuratio

Would be great idea to have this until SmarterTools have fixed, if they fix it. I will open a ticket at SmarterTools. 

[Andrew Penhorwood]

@Micha

I am constantly impressed with your desire to remove all performance issues.  You are the reason why I use Lucee as my CFML engine.

Andrew Penhorwood

[David Eurenius]

@Micha

I second Andrews view that it's really impressive the care and ownership felt over Lucee and it's code!

We have just switched from a ACF world and it's like night and day in the attention to feedback and the pursuit for a better platform.

I also like the idea to have a setting to change the behavior if needed.

--David

[Michael Muller]

Awesome. Thanks!

[Michael Offner]

There is a new patch available (4.5.1.004) on the "dev" update provider,  that allows to define if a specific mail server should reuse connections or not.

https://bitbucket.org/lucee/lucee/wiki/Update

This setting is pure experimental and not available in the admin frontend.

to use that setting open the {server-context}/lucee-server.xml, if the mail server is defined in server admin or the {web-context}/lucee-web.xml.cfm if the mail server is defined in the web admin.

There you find a section that looks like this, that holds your mail server definition:

<mail default-encoding="UTF-8" spool-enable="true" spool-interval="5" timeout="30">

<server reuse-connection="false" password="encrypted:..." port="587" smtp="smtp.gmail.com" ssl="false" tls="true" username="su...@lucee.org"/></mail>

set "reuse-connection" as you can see above and restart Lucee.

Micha

[Andrew Penhorwood]

I ran my test again with the new setting.  The delay is gone and it runs fairly quick.  Now if someone who has a real SmarterMail job could verify that this works we can call it fixed.

Andrew Penhorwood

To unsubscribe from this group and stop receiving emails from it, send an email to lucee+unsubscribe@googlegroups.com.

[buj...@gmail.com]

We recently ran into the "slowness" issue with Lucee using Sendmail as our local MTA.  After investigating it I found that it's an issue between JavaMail and any MTA that has throttling in place for NOOP commands.  In the JavaMail isConnected method it uses the NOOP command to see if the connection is good and does this before sending each mail message. The problem is that after 19 NOOPs sendmail starts slowing down because it thinks it's detecting a SMTP attack.

Javamail 1.4.x added an option to the SMTP Transport class called "mail.smtp.userset" where if it's set to "true" it will use the RSET command instead of the NOOP command in the isConnected method.

"If set to true, use the RSET command instead of the NOOP command in the isConnected method. In some cases sendmail will respond slowly after many NOOP commands; use of RSET avoids this sendmail issue. Defaults to false."

I tested this option by replacing the Lucee sun-mail.jar file (JavaMail 1.3.3) with the JavaMail 1.4.7 jar file and set the option mail.smtp.userset=true on server startup.  All 100+ emails went out within a few seconds compared to the hours it would take using the NOOP command in isConnected.

Would it be possible to upgrade Lucee to JavaMail 1.4.7 and add an option in the Server/Web Admin under Mail to select the command the isConnected method will use?

Brian Ujvary

[Andrew Penhorwood]

Did you try the reuse-connection switch?  Here is Micha's message from just a few post above.

Andrew Penhorwood

[buj...@gmail.com]

I did not because I don't want to incur the extra overhead of closing the connection after each email sent.  For now I worked around it in Sendmail by setting the MaxNOOPCommands to 0 in the Sendmail conf file.   This disables the auto-slowdown if multiple NOOP commands are sent during a single session but opens the mail server up to a potential NOOP denial of service attack.

Brian Ujvary

[Andrew Penhorwood]

Fair enough.  You might want to create a enhancement request so the issue get tracked.  Since this issue is different from the SmarterMail issue.

Andrew Penhorwood