Server Side Best Practices

I wonder if anyone can shed any light on what sorts of issues you have had to deal with on the server side for communication protocols. While I may be new, I have indeed seen that llEmail is our friend, like it or not, but there is no guidance available for server side best practices.

In general, do you think it is best to poll a web server from a web app and use some sort of a trigger to cause that page to be executed at a set interval (gawd -- I think I'm gonna hurl...)

Or have the better systems tied into their email systems, acting on mail immediately as soon as it is received?

Lastly, if anyone has some expertise in this area, I'd love to chat. I'd be happy to pay for your time of course...

Thanks!

You probably want your email to trigger a script. That's what I'm using - a .forward which sends it to procmail, then a .procmailrc file which sends it to a PHP script, and then the script does what it needs to do. No polling anywhere.

I do the same thing. In a little more detail:

I set up an alias on my server's /etc/aliases file, so that email the script sends to the server goes to my local user, lex. User lex has a .procmail setup that catches mail addressed to this special email alias and sends it through a perl script (substitute shell script, php script, C program, LISP script, assembly language, whatever you want) that I wrote to deal with the email. The program just reads its standard input, which is the email including headers (unless you tell procmail to send the body only, which can make parsing easier).

Since we're talking best practices here, I'll just get this out of the way: don't just put an alias to a pipe in your /etc/aliases, because your mailer daemon might be running that as root. If you do put a pipe alias in /etc/aliases, be very sure that the pipe program is NOT running as root. Otherwise, any tiny bug in your script might open your system up nice and wide to an attacker.

Hmm... I'll have to try this alias idea. I had to use my real email address (username@server.webhost.com instead of [email]username@mydomain.com[/email]), because mailsent to mydomain.com got processed on the host's main web server, so procmail would run there, which would try to call /usr/bin/php (or whatever) on the mail server, and fail. So I ended up having to use the local email address.

So... are you saying that an alias will cause the mail to get processed on the local server?

Thanks Lex and Ziggy. My setup is a Win2K3 box w/ASP.NET + SQL Server. I've tried hooking an executable into the spool using both SmarterMail and MailEnable as the mail server and both of them are giving me fits at the moment, but that is a whole nother issue!

Thanks for the advice. Keeping this whole thing secure is a pretty big consideration. If someone found the right alias to send to and what your message format looked like, you could have trouble. I think I have a system in place to minimize that risk, but its still a work in progress for sure...

Oh, hmm. Well, if the problem is that mail sent to the domain is delivered directly to a special mail server, then yes, you can probably use an alias to get around this (if your domain mail system supports it). You'd probably want to set [email]scripts-send-mail-here@mydomain.com[/email] to point to [email]username@server.webhost.com[/email], since you know that mail sent to [email]username@server.webhost.com[/email] gets delivered on a system with PHP. It's not critical to even have an alias like this, I just like to because it makes it easier to cut the flow off entirely if something goes horribly wrong.

I looked through the control panel on my web host last night, and I didn't see anything about aliases. I do have forwarders. Not sure if I can do the same thing with those. Worth trying.

I wish there were some way to have different [email]address@mydomain.com[/email] email addresses, that I could then send to different scripts. As far as I can tell, I can only set up one .procmailrc file, for my main (real) email address/login. So my only form of control is to redirect to the destination script based on the subject line in the incoming email.

Thanks for your help with this. If I can get this to work, then I can remove [email]login@server.webhost.com[/email] from future SL objects, which would definitely be a step forward.

Ziggy,
I use Dreamhost and what I did was go into my control panel and created a couple of "Forwarding Only Addresses" in the mail tab, one for each script. Then I edited my .forward.postfix file (Dreamhost uses Postfix) to point to my .procmailrc file.

You only need one .procmailrc file. In the file, you basically set up different "recipies", one for each email. Even though the "forward only addresses" just forward to your main email account, procmail can still see which forward only address the email was originally sent to. You can match that and pipe emails to that forward only address to the corresponding script.

Thanks. I was on DH too, until the big outage when LL - DH emails just stopped working. I finally gave up and switched hosts, and of course, the problem got fixed the next day.