Suggestion: fix email delivery speed with SmarterMail

dev google-group-archive
21

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

Andrew PenhorwoodOn Wednesday, February 11, 2015 at 5:50:58 PM UTC-5, Martin Schaible wrote:

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.

22

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 .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 .
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 .
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 .
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 .
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 .
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’}.

23

@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 PenhorwoodOn Saturday, February 14, 2015 at 7:53:46 AM UTC-5, Micha wrote:

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

24

@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.

–DavidOn Saturday, February 14, 2015 at 5:31:29 PM UTC+1, Andrew Penhorwood wrote:

@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

On Saturday, February 14, 2015 at 7:53:46 AM UTC-5, Micha wrote:

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

25

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

26

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 …)”

MichaAm Samstag, 14. Februar 2015 schrieb 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/

–
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+unsubscribe@googlegroups.com
<javascript:_e(%7B%7D,‘cvml’,‘lucee%2Bunsubscribe@googlegroups.com’);>.
To post to this group, send email to lucee@googlegroups.com
<javascript:_e(%7B%7D,‘cvml’,‘lucee@googlegroups.com’);>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CABPCP-00OzWikP%2Bt9jaZQ8p9%3DDB3h1OGFOwsBaKFQBt5uoCTzA%40mail.gmail.com
https://groups.google.com/d/msgid/lucee/CABPCP-00OzWikP%2Bt9jaZQ8p9%3DDB3h1OGFOwsBaKFQBt5uoCTzA%40mail.gmail.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

27

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.

28

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

29

Awesome. Thanks!

30

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 PenhorwoodOn Monday, February 16, 2015 at 4:46:02 PM UTC-5, Micha wrote:

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:

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

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

Micha

On Sat, Feb 14, 2015 at 1:53 PM, Michael Offner <mic...@lucee.org <javascript:>> wrote:

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

Am Samstag, 14. Februar 2015 schrieb 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/

–
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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CABPCP-00OzWikP%2Bt9jaZQ8p9%3DDB3h1OGFOwsBaKFQBt5uoCTzA%40mail.gmail.com
https://groups.google.com/d/msgid/lucee/CABPCP-00OzWikP%2Bt9jaZQ8p9%3DDB3h1OGFOwsBaKFQBt5uoCTzA%40mail.gmail.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

31

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:

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

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

MichaOn Sat, Feb 14, 2015 at 1:53 PM, Michael Offner <@Michael_Offner> wrote:

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

Am Samstag, 14. Februar 2015 schrieb 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/

–
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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CABPCP-00OzWikP%2Bt9jaZQ8p9%3DDB3h1OGFOwsBaKFQBt5uoCTzA%40mail.gmail.com
https://groups.google.com/d/msgid/lucee/CABPCP-00OzWikP%2Bt9jaZQ8p9%3DDB3h1OGFOwsBaKFQBt5uoCTzA%40mail.gmail.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

32

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 PenhorwoodOn Tuesday, May 19, 2015 at 4:00:45 PM UTC-4, buj...@gmail.com wrote:

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

On Tuesday, May 19, 2015 at 2:45:02 PM UTC-4, Andrew Penhorwood wrote:

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

Andrew Penhorwood

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:

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

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

Micha

33

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

Andrew Penhorwood

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:

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

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

Micha

34

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 UjvaryOn Tuesday, May 19, 2015 at 2:45:02 PM UTC-4, Andrew Penhorwood wrote:

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

Andrew Penhorwood

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:

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

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

Micha

35

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