Best way to handle outgoing mail ..
I have a single public IP that I tell them all to point the domains at, and I then route the traffic through to whichever node it needs to go to. The sites are mainly PHP, and they send emails using standard PHP mail libraries.
I have the simple Ubuntu 10.04 outgoing-only exim linode library set up, and let PHP handle the mail headers.
What is the best set up to make sure that email doesn't get marked as spam? Relay it through the public IP address? Get the clients to set up a rdns address that I always use as a the from address for that domain (with a different reply-to)? Make 1 single public domain name for that node and have all mails come from that? Or do I just need to set up rdns for the hostnames of each node?
I'd rather not have to configure connecting up (auth e.t.c) to their mail exchanges as that is a comparatively expensive bit of paper work for this type of project/site.
EDIT:
The rDNS is still set as default (li1234-56.members.linode.com) on all the nodes sending out email. This all works, as far as I can tell.
Is the issue that this doesn't match the 'From:' header domain? Is that what is caught is some spam traps?
Thanks.
6 Replies
@deadwalrus:
http://aws.amazon.com/ses/ Sorry, I don't see how that is relevant?
Another option is to have everybody use Google Apps, and tell everybody to set their sites to use their Google Apps SMTP server.
There was recently a topic (started by yours truly http://forum.linode.com/viewtopic.php?t=7888
And in case it helps, I had an issue recently with PHP sending out emails. My solution (a misconfigured iptables) might not be the solution you're looking for, but the other suggestions may help (though it seems like you have a good enough understanding of your issue already): http://forum.linode.com/viewtopic.php?t=7906
@graq:
@deadwalrus:
http://aws.amazon.com/ses/ Sorry, I don't see how that is relevant?
Deadwalrus is saying that the best way to handle outgoing e-mail is to outsource it.
But if you want to handle it yourself, what you're doing right now seems to be OK for the most part.
No, you don't need to relay all mail through a single IP address. You just need to make sure that each node that sends mail have a valid rDNS, which it would do by default. Exim should also identify itself using a correct fully-qualified hostname that actually points to the respective node's IP address. (Until recently I thought that the hostname should also match the rDNS, but it seems that this is not necessary.)
It does not matter if the hostname or rDNS of your node is different from the domain(s) of your web site(s). ISPs don't care about this part. (Otherwise, nobody on shared hosting would be able to send mail. They've got hundreds of domains pointing at the same server, you know.)
What does matter is to have a SPF record for each domain that explicitly permits the node to send mail on behalf of the domain. An SPF record is a special type of TXT record in a domain's DNS that lists which machines are allowed to send mail on behalf of the domain. Read up on it, and add the hostname(s) of any server(s) that might send mail on behalf of each domain. If you have a lot of domains and servers, you might want to use the "include:" syntax to simplify your life.
After that, it all depends on the receiving server. Some ISPs have ridiculous policies about mail sent from private servers, and you might not be able to fix that no matter what you do. But most ISPs are sane, and they'll accept your mail as long as the content doesn't look spammy. (Don't use all-caps in the subject; don't use external images in the body; don't use too many links in the body; don't pretend to be a Nigerian prince's nephew; provide an unsubscribe link if possible, etc.)
If your mail still goes into the spam bin, ask a few users to click "not spam". This definitely helps, especially with Gmail.
@hybinet:
What does matter is to have a SPF record for each domain that explicitly permits the node to send mail on behalf of the domain.
@graq:Most of my clients wish to handle domain registration, dns and mx configuration themselves, so assume that I have no control over that. Though I may be able to make suggestions.
This will be your biggest stumbling block - everything else hybinet suggested is under your control, but SPF must be handled in the client's DNS. If they already have an SPF record, then you need to get them to add the IP(s) of your outgoing mailserver to it. If they don't already have SPF then you are not technically violating anything by sending their mail, but many receivers may view lack of SPF as an indication of possible spam.
@Stever:
This will be your biggest stumbling block - everything else hybinet suggested is under your control, but SPF must be handled in the client's DNS. If they already have an SPF record, then you need to get them to add the IP(s) of your outgoing mailserver to it. If they don't already have SPF then you are not technically violating anything by sending their mail, but many receivers may view lack of SPF as an indication of possible spam.
Yes, the OP will have to contact the clients and tell them to add an SPF record, or even worse, modify an existing SPF record without breaking existing settings.
This is why the include:
If clients don't know how to modify their existing SPF records, or if you have reasons to suspect that they'll mess things up, do this: Just fetch their current SPF records using the public DNS, make the necessary modifications, and email your clients exactly what string to put in their DNS.
For example, a client who uses Google Apps might have the following SPF record:
v=spf1 include:_spf.google.com ~all
Change it to:
v=spf1 a include:_spf.google.com include:graq.example.com ~all
The "a" is there to make sure that whatever server hosts the website has the right to send mail (just in case something else goes wrong).