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?
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.
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.
MikeOn Tue, Feb 3, 2015 at 12:07 PM, Michael Muller <@Michael_Muller> wrote:
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?
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.
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.
MD> On 3 Feb 2015, at 17:22, Michael Sprague <@Michael_Sprague> wrote:
Why not use something like Mandrill (mandrillapp.comhttp://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
On Tue, Feb 3, 2015 at 12:07 PM, Michael Muller <@Michael_Muller mailto:Michael_Muller> wrote:
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?
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 …
… inside , then added …
executor=“tomcatThreadPool”
… to
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.
MikOn Tuesday, February 3, 2015 at 4:06:08 PM UTC-5, Martin Schaible wrote:
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.
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.
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 https://www.wireshark.org/to review the connection? We can solve this
issue.
Andrew PenhorwoodOn Sunday, February 8, 2015 at 1:33:21 PM UTC-5, Anton wrote:
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
On Tuesday, February 3, 2015 at 9:07:57 AM UTC-8, Michael Muller wrote:
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?
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,
AntonOn Tuesday, February 3, 2015 at 9:07:57 AM UTC-8, Michael Muller wrote:
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?
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.
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.
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 PenhorwoodOn Wednesday, February 11, 2015 at 12:11:05 PM UTC-5, Martin Schaible wrote:
@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.
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 PenhorwoodOn Wednesday, February 11, 2015 at 9:38:32 AM UTC-5, Michael Muller wrote:
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: 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.
