I am having somewhat of a discussion with the developers/support engineers of the forums software I use.
I am experiencing slow POST when someone replies to a message on my forums. After searching for days, it turns out, when someone replies to a forum post, the forums software waits for the topic notification emails to be send out before completing the POST, which then slows down the reply for about 5 seconds.
So I changed the mailer in the forum email settings to PHP. All goes blazing fast. Then change back to smtp on mailcow and it is slow again. After some searching it turns out that mailcow uses smtp transaction delays for preventing spam and whitelists the sender for some time after the first attempt.
Invison Community support says “get another provider/mailserver” I say: “Mail should be queued. POSTS should not rely on on an external system or network. There is no reason to wait for email to be send.”
My questions:
- Who is right in this case. What is best practice?
- How to resolve the issue without getting another provider/mailserver or forum software 😉
For reference my question and their response in the hidden support forums:
Hi,
On our forums we are experiencing extremely slow POST times (> 5sec) on our otherwise crazy fast server.
It took me very long to find the culprit as behaviour varied from topic to topic / time to time.
As I ruled out all possible server issues, I then focused on the actual differences in the topcis and then found out only topics that have followers took long. Most new topcis or topics I posted and then reply to myself did not.
Then I looked into the email settings, tried PHP as mailer (I use normally use SMTP) and then all posts where practically instant.
Turns out when posting messages, the forum software seems to wait for the email notifications being send. Seems to me this should be a separate (background) process or queue, as most SMTP servers have transaction delays due to spam prevention.
SMTP Transaction Delays
As it turns out, one of the more effective ways of stopping spam is by imposing transaction delays during an inbound SMTP dialogue. This is a primitive form of teergrubing, see: http://www.iks-jena.de/mitarb/lutz/usenet/teergrube.en.html
Most spam and nearly all e-mail borne virii are delivered directly to your server by way of specialized SMTP client software, optimized for sending out large amounts of mail in a very short time. Such clients are commonly known as Ratware.
In order to accomplish this task, ratware authors commonly take a few shortcuts that, ahem, “diverge” a bit from the RFC 2821 specification. One of the intrinsic traits of ratware is that it is notoriously impatient, especially with slow-responding mail servers. They may issue the HELO or EHLO command before the server has presented the initial SMTP banner, and/or try to pipeline several SMTP commands before the server has advertised the PIPELINING capability.
That makes SMTP unusable as a mailer.
Could IPS please clarify why the design seems to work as outlined and there is no queue or separate proces? Are you open to change this?
