Upcoming changes in Second Life outbound email

I'm going to be making some changes to the SL outbound email subsystem in the near future to help deal with the grid email problems that have been occuring.

Most of you will notice nothing different except that email from the grid will work a lot better; however, I know that some people have setup very restrictive firewall rules to only recieve SMTP from Second Life's SMTP server. I just wanted to let those people know that they should relax their firewall rules to allow SMTP from our entire IP ranges (66.150.244.0/23 and 69.25.104.0/23) if they would like to continue to recieve email from the SL grid.

I expect this change to go into place soon; I'm still doing testing on our dev grids to make sure nothing breaks.

Any questions?

Sounds good to me. I have no firewall rules.

Any specifics as to what is changing? What makes it better? Will there still be the long delay before sending an email? (I know that's for anti-spamming purposes, but just had to ask)

The xmit delay in llEmail() will remain, I'm afraid... it's not there for anti-spam purposes really, it's more of a resource consumption limiter (as are most of the LSL delays). Sending out an email is a fairly expensive operation (in terms of single function calls that LSL can do).

What is changing (more or less) is that each simulator node will now handle its own outbound email (as opposed to now, where they get relayed through a central SMTP host). This should alleviate many of the scripted email problems, since each region will have its own mail queue, independent of the other regions (more or less... some regions will still share queues, but it will only be a few to a queue, so to speak).

This means that a hostile or badly written scripted object could still nuke the queue for the region that it is on if it tries hard enough, but it won't affect the rest of the grid at all (and it will be much easier for us to determine where the problem is coming from and we should be able to fix it more quickly, too).

As you can imagine, ensuring that this works correctly across the 400+ sim nodes takes a bit of work, which is why this is taking so long.

Thanks for the thorough and prompt reply, Mark! Sounds like the right way to go. Will the mail queues affect performance of the sim its attached to at all? Or are they seperate machines than the actual sim machine?

The only performance impact should be that llEmail() latency improves considerably. The queues are on the same hardware as the simulators; however, the mail system consumes almost no CPU (but does use disk IO), whereas the simulator consumes almost no disk IO (but does use CPU). They are on the same hardware, though. If it turns out that my testing was incorrect, we'll figure out another solution, but I'd be suprised.

On the other hand, it's unlikely that it would be worse than it is currently.

Yay! So now only 1 in 400 (holy fuxx0r! 400? No way! I thought it was just something like 275 sims!) people will be affected by multithreading Email goodness!

So, when are you going to get around to Obj<->Obj communication via XML-RPC? Hasn't it been more than six months?

No. Wait. I'd rather have particle system improvements, land LSL calls, and other various features instead. Keep delaying implimenting XML-RPC!

Just wanted to let everyone know that the outbound email fix was deployed today, and appears to be working fine. More details can be found at the Linden Ops blog: http://secondlife.blogs.com/ops/

Thanks for letting us know about this Mark.

Also, the blog is very cool and interisting to read, please make updates to this when time permits as reading these blogs are interisting to me.

Postfix - excellent smtpd choice. I definitely noticed the difference this weekend. Thanks!