chris
27.Jul.05 14:55
|
I've been keeping an eye on thomas murray's and laculine's mail server recently, and I noticed a small thing about the rap-x mail:
When an e-mail is sent, it seems that an identical message is sent to all possible recipients using a separate SMTP connection for each recipient.
This works fine, but it's not efficient, on two counts:
1) It creates a lot of SMTP connections.
2) The data is sent multiple times.
Here's a chunk from the mail.laculine.com log:
2005-05-05 03:45:12 1DTWMR-000240-V7 <= supportXXX.net
2005-05-05 03:45:12 1DTWMS-000243-3B <= supportXXX.net
2005-05-05 03:45:12 1DTWMS-000245-AG <= suppoXXX.net
2005-05-05 03:45:12 1DTWMS-000247-Fk <= supportXXX.net
2005-05-05 03:45:12 1DTWMS-000249-L5 <= supportXXX.net
2005-05-05 03:45:13 1DTWMR-000240-V7 => alanekXXX.com
2005-05-05 03:45:15 1DTWMS-000245-AG => a.meolaXXX.net
2005-05-05 03:45:15 1DTWMS-000243-3B => w.dunnXXX.net
2005-05-05 03:45:15 1DTWMS-000247-Fk => corrine.lennon@sonichealth.com.au
2005-05-05 03:45:15 1DTWMS-000249-L5 => robert.XXX.com.au
There are 5 connections made all at once (from turbot.laculine.com to mail.laculine.com), where 1 would suffice. The mail is then sent to 3 different domains, again making 5 separate connections where 3 would suffice.
Because rap-x mail is, by nature, often sent to many people in the same domain, the inefficiency is passed on to that domain's server as well. If a mail server scans the content (as is increasingly common), this will present more of a problem because of the duplicate scanning.
I've marked this as "Discussion" because it's not a bug, and I don't actually know the detail of the mailing code implementation, so I might have got some details wrong.
|
|
patrick
05.May.05 11:23 |
What is the alternative? Are you suggesing sending one message, with everyone's address in the BCC field? This would require us to depersonalise the messages (which may be a good thing anyway). |
|
oleg
05.May.05 11:39 |
I agree that it can be optimised, but it will not be exactly the same: our emails has proper "To" header. Emails sent in bulk would not.
This however is probabaly not important.
As for depersonalisation, we already support it. In notif.xml we can specify whether email message is constructed individually for every recepeint or it is constructed once. But this does not affect the sending procedure which is caried out individually for every recepient.
In order to make it more efficient in terms of connections, we should probably try to group users by email domain (which we can't do currently) or by organisation which almost the same. |
|
chris
05.May.05 11:40 |
Of course - it isn't the same message being sent each time at all. So there is no alternative unless the message is depersonalised.
An alternative to bcc is to use multiple SMTP RCPT TO commands. But this should all be handled by some SMTP library. |
|
oleg
05.May.05 11:46 |
Another note.
In rap-x we do not open concurrent connections to the smtp host (within one notification thread).
And we always wait for sending to complete, i.e. the sending is not asyncronous. If this by some reason reasult in multiple simultaneous connections then this is probably out of our control. We use Java Mail library, I'll check whether there are any optimisations possible. |
|
chris
05.May.05 11:55 |
>In rap-x we do not open concurrent connections to the smtp host
Fair enough. In the example I quoted from the mail.laculine.com log, the connections are all from turbot.laculine.com. The surity rap-X site delivers mail to turbot.laculine.com, which uses mail.laculine.com as a smarthost. This is why the connections end up being simultaneous: rap-x can deliver lots of mail to the local SMTP server very fast, and this results in multiple connections from turbot->mail.laculine.com, because these connections (doing the actual delivery) last longer.
So this is out of the control of rap-X. |
|
patrick
05.May.05 13:24 |
I don't think we need to support personalised emails. If this allows to consider further optimisations to the sending procedure, I think this is worth considering. |
|
patrick
27.Jul.05 14:55 |
is this still an issue? Are we realistically going to do anything to resolve it? If not, let's close this request. |
|
