Mail relays or SMTP services for use in code - email

I'm looking to start using an SMTP or mail relay service. I've found quite a few out there, but I'm not sure if there are advantages to one vs another. The only requirements I have are:
can send "from" more than 1 domain (possibly >20 for all the different sites I work on)
can pay for a higher limit (I may need to send as many as 15000 in 1 day, although the average is <500)
can send from PHP (although I doubt this will be a problem as most are compatible with any language)
I'm okay with an SMTP service, mail relay service or a site that uses a custom API, although an API would make the conversion more difficult.
Reasons for wanting to do this:
I don't want to host any mail services my self as they just cause head aches
I don't have to worry about being blacklisted. If they are blacklisted they will know about it and have the knowledge to get it fixed.
Reporting on if emails have gone through would be nice.

I'm not sure why you would need this. If you read the proper RFCs (822, 2822, 823, 2823), you should be able to connect to any given site directly using SMTP. You need to be a little careful with Line Endings (should always be CRLF), and should probably add mail.add_x_header = OFF to your php.ini.
However, if you need a relay, I recommend using a spam filtering provider, as then you have protection from being blacklisted due to spammers abusing email-generating forms. I would recommend Red Condor for this task, but that is only because I work there, and know that we can handle it.

I've started using Mandrill and found it to be a great, reliable service provided by MailChimp that includes enough for most sites to use for free. Easy to setup, but also has a lot more functionality available.

Related

Mailjet: alert on undelivered recipients

I'm aware this may not be the right place to ask this, but I don't know where else and others may encounter the same issue.
I'd like to have an aggregated view (or an alert) when some recipients in my contact list don't receive any of the emails my app sents. Is this possible?
I checked on the alert thing in the docs but it doesn't seem to do what I need. Although this seems like a pretty common need and there may not be necessary to setup webhooks and own app logic to handle this, wouldn't it?
Thanks
I have also faced same issue with cPanel and many other providers like Mailchimp. This usually happens due to Empty Subject due to which Cross-Server Contacts may not happen. Also, if you are using PHPmail() or sendmail function instead of SMTP, You need to be using TLS1.2 or TLS1.3 though 1.0 is also supported but many of my E-mails were not delivered so I upgraded to TLS 1.3 . Also, Check if your mail goes to Spam Folder. In that case, increase your Website and Domain Score and Try to rank in Google Safe Browsing. Also, this also happens due to misleading Hosting Provider whose SMTP servers are not setup correctly or Provider send many spam messages due to which, you domain score may got low. I currently use interserver_smtp and cloudmate_smtp collectively for all my clients as interserver deliverablility in India is low and cloudmate works in both texas and india correctly. Try cPanel or Plesk as it has the best deliverability. One More thing, This could also be an issue of DNS. Check your DNS settings if MX records are pointed to MailJet Servers.

Postfix, isolate multiple sites mail headers so if one get's blocked/blacklisted, the others sharing the server don't also get blacklisted

I have a few separate sites on a server with a single IP.
The sites shouldn't ever send spam, but the customers are free to send emails from their sites so I have no way to prevent them from doing so.
What I'd like to do is when sending the emails via postfix, somehow separate the sites in the headers sent out.
Previously i've setup an ip for each but i'm trying to avoid doing this.
I've also found with /etc/postfix/header_checks I can remove headers but not sure if removing specific headers will cause issues?
One thing to consider here is that blacklisting is usually based on IP addresses. Separate headers won't help much there. The reason for this is that (a) it's simple and (b) many spam sending servers have been compromised and taken over by an attacker, using custom mail sending software, so headers don't matter anymore.
Different headers might still have their merit though, as spamfilters will check those. It just won't help if your server's IP gets blacklisted.
I guess rolling out DKIM might help here, it would give you artificial separation of domains using different domain keys for each. There are some good tutorials on the net on how to set it up with OpenDKIM.
A better solution, used by big mail providers like GMX, is to send mail from a separate IP if it looks like its spam. The setup for this is a little complicated, as it requires you to scan outgoing mail with spamassassin (or something similar) and to route mail depending on the respective spam value. Not an easy task. Marking spam as such, without sending it through a separate IP, might enough to convince the other side that you try to prevent spam send from your server, but this really depends on their spam filter.
The way your server identifies itself during an SMTP conversation is through the HELO command. The smtp_helo_name parameters specifies the name used there. One could try to setup a transport mechanism to use a different name for each sender domain. I'm honestly mot sure how difficult that would be.
If you are still set on changing headers: the header_checks tables not only allow to remove headers, but also to alter them via regular expressions.
Use the REPLACE command to do so. Example:
/^(Message-ID:.*)#your-domain.example(.*)/ REPLACE ${1}#other-domain.example${2}
I'd advise against it, though. It provides to little gain for the effort of finding and setting up the right rules.

Possible to use server for collecting and distributing mail

We currently have POP3 mail accounts where I am and try as I might to convince my manager that we should be using hosted IMAP or Exchange he won't budge because of the cost. The staff are mostly out of office so there is no domain server here, however, we do have a dedicated server and I wondered whether I could use this to collect the mail and distribute it from there in some way.
Effectively what I'm trying to do is ensure mail is stored somewhere other than the end users machine because backups are user dependant at the moment. With hosted Exchange or Exchange on this server would be simple but my manager won't shell out for it. I have seen free mail servers called MailEnable and Axigen but unsure if they will do the job. Sorry if this seems like an easy or stupid question but never needed to do this before.
I am assuming due to the reference to Exchange that you are on Windows.
If you have an old box lying around that works, you could install linux on it and then choose from a number of different imap servers. Dovecot and Courier are both good choices and I have worked with them before.
You could use fetchmail to then pick up the mailboxes and then deliver to the imap boxes or get them deliver directly.
Setting up such a linux server for email was one of the first things I ever did on Linux. While initially daunting, once you get the hang of it, it is pretty straightforward and there are plenty of resources out there to help.
Ubuntu is probably the easiest to get used to. CentOs is also a reasonable choice.
You shouldn't be running your own server if you aren't willing to administer your own server, and they are not easy to configure if you don't know what you are doing (e.g., you mess up and you are exploited for spamming).
Look into a service like mailgun. In my application we are using them for forwarding to REST endpoints as well as onto another SMTP server.
Competitors that wound up not meeting my needs but may meet yours include Dyn, email yak, Sendgrid, etc. etc.
Why not just setup the mail clients to store their mail files on a standard network drive or share? I follow that this situation is pretty silly in your view - 100% because of the ridiculous constraints that you are being asked to work within: I would similarly find the solution I am suggesting ridiculous generally; but under the circumstances, it seems like a simple answer to your problem - replacing distributed mail storage and backup with centralized storage and backup.
Don't POP3 email clients have the option keep a copy on the server? Mine certainly does. See second tick box on the pic.
You can then periodically take a back up of all the emails from the server to stop it getting clogged up.

PEAR::Mail vs. PHP: Mail

I am creating a PHP system that will forward emails, (ie. someone#emailforprofession.com to someone#gmail.com) without using an SMTP server which is faster and more stable? PEAR::Mail or PHP: Mail? (or another one entirely)
I would be using extra headers and attachments but mainly trying to keep it looking and acting the same. (if anyone has an example for forwarding with attachments PLEASE provide it!)
And not exactly on the side but is there a way for people to be able to send email from they're someone#emailforprofession.com email address without having a complete inbox etc?
It would probably be better for me to use a real email provider but these are supposed to be free email addresses so paying by the email address is not an option, if anyone knows of a service that: charges by the month or year, has an API that email addresses can be created from and that can set up email forwards via the API that would be most appreciated.
I currently have a partial system together but would like to know which way I should go first.
Thank you all.
The PEAR class supports multiple mailer backends, which allows you to
switch whenever needed and you'll be able to perform some benchmarks
and see which backend suits you best. The native mail function on the
other hand is much less advanced and will show a clear difference in
performance, especially for that amount of mails.
I also suggest you have a look at PEAR's mail queue class:
http://pear.php.net/package/Mail_Queue
This is much more recommended for larger projects such as yours,
you'll also be able to implement a cron like feature which will send a
certain amount of mail per period you choose.
Here

Guidelines for email newsletter service

I'm implementing a email newsletter sender service using .NET and Windows Server technologies. Are there comprehensive guidelines which could help avoiding emails being trapped by spam filters and other mechanisms?
They should cover all aspects of (legal) bulk mail sending: SMTP configuration, DNS, HTML content, images, links within content etc. A simple example: is it better to embed images or load them from a server?
It would be great if you could provide some empirical data to show the efficiency of some measures taken.
Although I don't have a definitive answer, I think this is a very important question.
Here are few tidbits I know about it
Choose a clean hosting/smtp server. IP addresses of spamming SMTP servers are often black-listed by other ISPs.
Send a simple introductory email to every subscriber, asking them to add your sender address to their safe list.
Be very prudent in sending to only those people who are actually expecting it. You wouldn't want pattern recognizers of spam filters learning the smell of your content.
If you don't know your smtp servers in advance, its a good practice to provide configuration options in your application for controlling batch sizes and delay between batches. Some servers don't like large batches or continuous activity.
Unless you have a very specific reason to host the newsletter yourself, I think you'd be much better off using a third party service. There are lots out there, and some are very cheaply priced.
It'll save you on development work
(no point in re-inventing the
wheel).
Their system will handle all
the unsubscribe link stuff that you
need to include in email newsletters
to comply with CAN SPAM laws or
whatever.
They handle the spam
reports that you will inevitably get
if you have a list of any non-trivial size.
They keep records of who signed up,
how they signed up, and their IP
address, and can present those on
receipt of a spam report to prove
that their service wasn't sending
out spam.
You can use double-opt in
(or confirmed opt in), for extra
evidence to prove that the people
you're sending emails to actually
signed up to receive them.
If you really do need to host it yourself I'd suggest you search the web for "email deliverability". Things that are known to help include properly set up SPF records, DomainKeys/DKIM, correct DNS settings (reverse DNS especially - best to just use an online service to check your DNS settings). You can test a lot of these things by sending an email to check-auth#verifier.port25.com.
It's best to avoid using spammy words in your email - always a bit of guesswork this but you some words can trip filters.
But I'd guess that by far the most important thing is to be sending your email from a trusted server that maintains good relationships with ISPs (i.e. ensuring that ISPs don't think that the server is sending out spam). This is a big reason why it's much much easier to get a third party to handle everything for you.