CODEWITHSUNDEEP
phpemailiissmtpswiftmailer
Janus Bahs Jacquet
Janus Bahs Jacquet

Reputation: 920

(PHP + SMTP) Sending data takes 10 seconds

I am trying to send a newsletter from the website of the company where I work. To do so, I am using a SwiftMailer SMTP transport. I’m building the sending mechanism and everything in PHP, run on a Windows 2008 server with IIS 7.5 (I think).

Our server, company.fac.university.com is located within the network of the university faculty that hosts us, fac.university.com. The university SMTP server, mail.fac.university.com, is the only one on the network not firewalled out of sending on standard e-mail ports; so my PHP script connects to mail.fac.university.com using university credentials to authenticate.

So far so good.

The problem is that sending e-mails through this script is extremely slow. Each mail takes about 10 seconds to send. I have tweaked the standard SwiftMailer Logger Plugin to not only output the raw SMTP communication, but also display the timestamp of each individual message. This has shown me that everything is actually quite fast and normal-looking, except the actual act of sending data to the SMTP server. That, for whatever reason, takes 10 seconds (and a bit—somewhere between 10 and 11 seconds).

The SMTP output looks like this:

16:08:26 ++ Starting Swift_SmtpTransport
16:08:26 << 220 mail.fac.university.com Servername Enterprise mailer (ver. 3.9) 
16:08:26 >> EHLO company.fac.university.com 
16:08:26 << 250-mail.fac.university.com 250-PIPELINING 250-SIZE 37748736 250-VRFY 250-ETRN 250-STARTTLS 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN 
16:08:26 >> STARTTLS 
16:08:26 << 220 2.0.0 Ready to start TLS 
16:08:26 >> EHLO company.fac.university.com 
16:08:26 << 250-mail.fac.university.com 250-PIPELINING 250-SIZE 37748736 250-VRFY 250-ETRN 250-AUTH PLAIN LOGIN 250-AUTH=PLAIN LOGIN 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN 
16:08:26 >> AUTH LOGIN 
16:08:26 << 334 VXNlcm5hbWU6 
16:08:26 >> bnB3NDM1QGt1LmRr 
16:08:26 << 334 UGFzc3dvcmQ6 
16:08:26 >> U2hhaGFiMTIz 
16:08:26 << 235 2.7.0 Authentication successful 
16:08:26 ++ Swift_SmtpTransport started
16:08:26 >> MAIL FROM: <[email protected]> 
16:08:26 << 250 2.1.0 Ok 
16:08:26 >> RCPT TO: <[email protected]> 
16:08:26 << 250 2.1.5 Ok 
16:08:26 >> DATA 
16:08:26 << 354 End data with <CR><LF>.<CR><LF> 
16:08:37 >> . 
16:08:37 << 250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 6B11D200A0A0 
16:08:37 >> MAIL FROM: <[email protected]>
16:08:37 << 250 2.1.0 Ok 
16:08:37 >> RCPT TO: <[email protected]> 
16:08:37 << 250 2.1.5 Ok 
16:08:37 >> DATA 
16:08:37 << 354 End data with <CR><LF>.<CR><LF> 
16:08:47 >> . 
16:08:47 << 250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as B4F9E200A0A0 
16:08:47 >> MAIL FROM: <[email protected]>
16:08:47 << 250 2.1.0 Ok 
16:08:47 >> RCPT TO: <[email protected]
16:08:47 << 250 2.1.5 Ok 
16:08:47 >> DATA 
16:08:47 << 354 End data with <CR><LF>.<CR><LF> 
16:08:57 >> . 
16:08:57 << 250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as DA987200A0A0
16:08:57 ++ Stopping Swift_SmtpTransport
16:08:57 >> QUIT 
16:08:57 << 221 2.0.0 Bye 
16:08:57 ++ Swift_SmtpTransport stopped

(<< meaning “message received from SMTP server” and >> meaning “message sent to SMTP server”.)

I have tried using phpMailer and even bare PHP mail() as fallbacks, with no change. I’ve also tried switching between ports I connect through, with and without TLS/SSL, etc.—no change. The e-mail I’m sending is multipart (HTML + plain text) and about 5 KB in size. I’ve tried paring it down to a simple plain-text mail less than 100 bytes in size, which also made no difference whatsoever.

Being a relative n00b in the world of mail servers, I’m pretty much at my wits’ end here. Is the university server throttling the script? (And why is it my own sending that’s slow, then, rather than the server’s replies?)

What can explain this delay? Can I fix it; and if so, how?

Upvotes: 1

Views: 955

Answers (1)

Janus Bahs Jacquet
Janus Bahs Jacquet

Reputation: 920

It turns out that the university server was indeed (sort of) throttling the connection. It was running all manner of spam and virus tests on each individual e-mail before sending, and rather than accept the e-mail into an internal queue immediately and process it there, it waited until the processing was complete before returning an SMTP reply.

So the solution (arrived at after lots of frustrating being thrown around IT departments) was that The Powers That Be granted mail sent through scripts on our server rights to bypass the spam and virus checks.

Upvotes: 1

Related Questions