views:

568

answers:

3

When developing an application that sends out notification email messages, what are the best practices for

  1. not getting flagged as a spammer by your hosting company. (Cover any of:)
    • best technique for not flooding a mail server
    • best mail server products, if you were to set up your own
    • sending messages as if from a specific user but still clearly from your application (to ensure complaints, etc come back to you) without breaking good email etiquette
    • any other lessons learned
  2. not getting flagged as spam by the receiver's client? (Cover any of:)
    • configuring and using sender-id, domain-keys, SPF, reverse-dns, etc to make sure your emails are properly identified
    • best SMTP header techniques to avoid getting flagged as spam when sending emails for users (for example, using Sender and From headers together)
    • any other lessons learned

An additional requirement: this application would be sending a single message to a single recipient based upon an event. So, techniques for sending the same messages to multiple recipients will not apply.

+4  A: 

best technique for not flooding a mail server

not a lot you can do about this beyond checking with your mail server admin (if it's a shared hosting account / not in your control). but if the requirement is one email to a single recipient per event, that shouldn't be too much of an issue. the things that tend to clog mail systems are emails with hundreds (or more) of recipients.

if you have events firing off all the time, perhaps consider consolidating them and having an email sent that summarizes them periodically.

sending messages as if from a specific user but still clearly from your application (to ensure complaints, etc come back to you) without breaking good email etiquette

you can accomplish this by using the "Reply-To" header, which will then have clients use that address instead of the From address when an email message is being composed.

you should also set the "Return-Path" header of any email, as email without this will often get filtered off.

ex.

From: [email protected]
Return-Path: [email protected]
Reply-To: [email protected]

configuring and using sender-id, domain-keys, SPF, reverse-dns, etc to make sure your emails are properly identified

this is all highly dependent on how much ownership you have of your mail and DNS servers. spf/sender-id etc... are all DNS issues, so you would need to have access to DNS.

in your example this could present quite the problem. as you are setting mail to be from a specific user, that user would have to have SPF (for example) set in their DNS to allow your mail server as a valid sender. you can imagine how messy (if not outright impossible) this would get with a number of users with various domain names.

as for reverse DNS and the like, it really depends. most client ISP's, etc... will just check to see that reverse DNS is set. (ie, 1.2.3.4 resolves to host.here.domain.com, even if host.here.domain.com doesn't resolve back to 1.2.3.4). this is due to the amount of shared hosting out there (where mail servers will often report themselves as the client's domain name, and not the real mail server).

there are a few stringent networks that require matching reverse DNS, but this requires that you have control over the mail server if it doesn't match in the first place.

if you can be a bit more specific i may be able to provide a bit more advice, but generally, for people who need to send application mail, and don't have a pile of control over their environment, i'd suggest the following:

  • make sure to set a "Return-Path"
  • it's nice to add your app and abuse info as well in headers ie: "X-Mailer" and "X-Abuse-To" (these are custom headers, for informational purposes only really)
  • make sure reverse DNS is set for the IP address of your outgoing mail server
Owen
A: 

first a quick correction to the previous

return-path: is a header added by recieving system based on the envelope-sender of the incomming message

for spf to work the return-path/envelope-sender needs to be [email protected]

and ensure the spf record for yourdomain.com {or if per-user spf} for [email protected] allows mails to originate on the server that hosts the app/sends the email

this envelope-sender is the address that will recieve all bounces/errors

now sender-id is different entirely it checks the return-path/envelope-sender and the from: address {stored inside the message} if sending from: hisname [email protected] reply-to: hisname [email protected]

this will be a non-issue if sending from: hisname [email protected]

it will be and you must add a Resent-From: hisname [email protected] as this specifies to ignore the from: for sender-id checks use this instead as it has been sent by you on his behalf

Alan Doherty
A: 

now for the other bits that are worthwhile

ip's mentioned are your mailservers

a have your ip's ptr point to a name that also resolves to the same ip FQDNS

b have your server helo/ehlo with whatever.domain.com where domain.com is the same as the domain of the name in step A {not the same name for resons below}

c have that helo/ehlo servername also resolve to the ip of your server

d add the following spf record to that helo/ehlo name "v=spf1 a -all" {meaning allow helo/ehlo with this name from ip's this name points to only}

e add the following sender-id lines to the helo/ehlo name {purely for completeness "spf2.0/mfrom,pra -all" {ie there are no users@this-domain}

f add the following spf to the FQDNS-name and any other hostnames for your server "v=spf1 -all" {ie no machines will ever helo/ehlo as this name and no users@this-domain}

{as the fqdns name can be determined by bots/infections its better to never allow this name to be used in helo/ehlo greetings directly it is enough that it be from the same domain as the helo/ehlo identity to prove the validity of both}

Alan Doherty
oh all this and more onhttp://www.alandoherty.net/info/mailservers/
Alan Doherty