Email Sending FAQ
- Email Sending with Dada Mail FAQ
- Related FAQ's
- What's the difference between the Sendmail Command and SMTP?
- Which one should I use, the sendmail command or SMTP?
- SMTP Sending
- What does Dada Mail use for its SMTP Sending?
- SMTP Authentication
- SASL Authentication.
- What username and password are you supposed to give the SMTP server?
- How do you know you're supposed to use SASL authentication?
- POP-before-SMTP Authentication
- Testing Your SMTP Sending
- How can I enable SMTP sending using SSL/TLS?
- Is there a bounce handler for Dada Mail?
- Where are my bounce messages going?
- Dada Mail and Google Apps for Domains
- Before you begin
- Do not SEND email using Google Apps
- Use your local mail server/sendmail command to send mail
- Using Bridge for Discussion Lists
- Using Bounce Handler
- Write an HTML message, receive it as PlainText
- No Mail is Sending at All.
- Set your $MAILPROG to a file, instead of piping to sendmail
Email Sending with Dada Mail FAQ
This FAQ attempts to answer questions specifically to sending out email from Dada Mail.
Mass Mailing Sending FAQ
What's the difference between the Sendmail Command and SMTP?
Both SMTP sending and using the sendmail command do the same thing - they send email.
The SMTP engine will connect directly to an SMTP server.
The sendmail command will pass an email message to a server utility, which will then connect to the outgoing mail server.
Which one should I use, the sendmail command or SMTP?
If the sendmail command works, there's no reason to use SMTP directly.
Some reasons you may want to use SMTP sending:
Your mail server is located on a different physical computer than you hosting server
You do not have access to the sendmail command
You want more control over when your bounced messages are going
What does Dada Mail use for its SMTP Sending?
Currently, Dada Mail uses the Net::SMTP CPAN module to send email via SMTP. More information:
One of the main disadvantages of using the, Send via SMTP feature in Dada Mail is actually, setting up a mailing list to use it. Not that you have to jump through flaming hoops to do so, it should be very similar to how you'd set up a desktop mail reader to send messages. But, if you haven't done that, it can be slightly intimidating.
Currently, there are two different authentication schemes that Dada Mail supports for sending via SMTP.
Note: Be very wary if your SMTP server requires no authentication. This is also known as an, "open relay" mail server. Any mail sent through an open relay these days will be black listed by spam filters. Because of this fact, most SMTP servers require some sort of authentication.
Only use an SMTP server that does not require authentication when the server has some other way of being selective on who connects to it. For example, your SMTP server may just be, localhost and will only accept local connections. In this setup, it would be OK to use SMTP sending without authentication.
The first SMTP authentication scheme is called, SASL Authentication.
Basically, Dada Mail will log into an SMTP mail server and the SMTP mail server will ask for the correct username and password. When Dada Mail gives this to the SMTP mail server, it can then send mail. Pretty simple.
What username and password are you supposed to give the SMTP server?
The username and password that you want to give the SMTP server is either:
The List Owner's Email Address
The List Admin's Email Address
Usually, I check the option in Mail Sending: Options, Set the Sender of SMTP Mailings to the List Administration Address (under, Advanced SMTP Options
). If I have to use Authentication with the SMTP server, it will then use the List Admin's username/password information
How do you know you're supposed to use SASL authentication?
Usually, the documentation provided by your hosting company will tell you if you need to use SASL authentication. If you do not need to use SASL authentication, you'll most likely need to use POP-before-SMTP authentication.
POP-before-SMTP Authentication is slightly different than SASL Auth. Instead of the SMTP mail server requesting the appropriate username and password to log into the SMTP mail server, you'll instead have to first, successfully log into the POP mail server.
To clarify, a POP mail server is usually used to fetch received mail, as opposed to an SMTP mail server, which is used to send mail. So POP mail server: receives mail; SMTP mail server, sends mail.
The SMTP server will know if you've recently successfully logged into the POP mail server and if so, will allow you to send mail through the SMTP mail server. Sounds weird, right? I think so too.
Again, you'll probably want to use the list owner's email address's username/password to log into the POP mail server and again, your hosting company will most likely let you know which authentication is required.
Testing Your SMTP Sending
In the Manage List: Mail Sending: Options list control panel, you should see a button labeled, Save, Then Test. Clicking this button will both Save your SMTP settings and test the settings to see if they work.
Testing basically involves connecting to the SMTP server and attempting to send a message out.
What you'll see in the test results is the actual communication between the (sometimes POP3 server if you're using POP-before-SMTP auth) SMTP server and Dada Mail.
Sometimes, you can tell if you'll need SASL authentication when you see something similar to the following line:
Net::SMTP=GLOB(0x56054)<<< 250 AUTH LOGIN PLAIN CRAM-MD5
This means, the server requires SASL authentication, in either the, LOGIN, PLAIN or, CRAM-MD5 type. Note! that sometimes SMTP servers advertise SASL authentication, but actually do not support it. Confusing? Yes.
If you have problems with SASL Authentication, you'll usually see a message like this:
[Sun Jan 21 17:35:59 2007] mail.cgi: Problems sending via SMTP: at /Library/WebServer/CGI-Executables/dada/mail.cgi line 3295
If you do ask for help with debugging a problem connection, make sure to never post your password on any public mailing list/message board. It may be difficult to see, since your password will be encoded, but it's easily decoded.
Net::POP3=GLOB(0x54710)>>> APOP user%example.com 15e134ff8f404386b79613cfd3254d6f
15e134ff8f404386b79613cfd3254d6f is the encoded password.
Another way to continually see these verbose results of ever SMTP connection made is to tweak the Config.pm variable, %CPAN_DEBUG_SETTINGS. The two key/value pairs you'll be interested in are:
NET_POP3 => 0, NET_SMTP => 0,
Change the 0 to 1 To have extremely verbose debugging information in your error log (set up your error log as well)
How can I enable SMTP sending using SSL/TLS?
You'll need a few things, none of which we can really bundle with Dada Mail (unfortunetly)
The OpenSSL C Library
The IO::Socket::SSL CPAN module
If you were hoping that you can just use SSL connections with Dada Mail - you can, but you'll need a few things already available on your server. The upshot is that these things may already be available. The downshot is, if they're not, it can be difficult to install, if you are not well-versed in administrating your own webserver. But, the support in Dada Mail is there.
Is there a bounce handler for Dada Mail?
Where are my bounce messages going?
Bounces will go to which ever email address is set in the Return-Path of your email messages. Look at the source of an email message sent by Dada Mail, to find where the Return-Path header is set.
A brief tutorial in email sending:
An email message has basically two parts: the Message Headers and the Message Body. The Message Body is the easiest thing grasp - it's the message itself. The Message Headers all serve different roles, but a few should be familiar to anyone.
For example, the Subject: header is where the subject of the message is, the From header tells you where the message originated from, the To: header tells you where it's going. Easy enough. I'll throw in two more headers at you, that sometimes do not visually appear when you view a message in your mail reader.
The first is the Reply-To header. It'll hold a email address, just like the From: and To header. When you reply to a message, and the Reply-To header is present, it'll be sent to that address. If the Reply-To header is not present, your message will be sent to the email address that's present in the, From header.
The other header I want to talk about is the Return-Path header. This header also contains an email address and serves a similar purpose as the Reply-To: header, but is instead used for automatic response systems - like when a server bounces your message back, or a vacation script sends a note to you. It'll never be used by a real live human being, so it's not something you need to check.
So, in general:
Saying all that, Dada Mail's list administrator should be what's being set in its message Return-Path.
By default, this is probably not the case - you'll have to do some minor tweaks to your list. If you don't, the best bet is that the Return-Path header is set to a email address that is quite foreign to you.
Depending on how your Mail Sending Options are setup, you need to do different tweaks. Here they are:
Setting up the Return-Path when sending via SMTP
In Mail Settings - Options check,
Set the Sender of SMTP mailings to the list administration email address
You're all done.
Setting up the Return-Path when sending via the sendmail command line
Usually this works:
In Mail Settings - Options check,
Add the Sendmail '-f' flag when sending messages
You're all done.
After checking this option, test and see if mailing is still functioning. Depending on how Sendmail is setup, this could in fact stop messages from being delivered.
If this doesn't work, uncheck that option and try checking,
Print the 'Return-Path' header in all list emails
In my findings, this sometimes works for servers running Qmail - although you're not supposed to be able to directly set the Return-Path header.
And, that's it.
Now that you know how to set the Return-Path header, put it to some good use! Set up the Bounce Handler for Dada Mail:
Dada Mail and Google Apps for Domains
Many people use Google Apps alongside their other resources available with their hosting company.
There is a possibility that you can use Dada Mail in such a situation.
Before you begin
Double check that you have support to send messages using an SSL connection. If you can't - if these options are disabled in Dada Mail, you may be out of luck.
Do not SEND email using Google Apps
One major limitation of using Google Apps for your email needs is that the daily email sending limitation per account is around 250 messages. This makes running a mailing list fairly unrealistic and is the largest problem we'll need to overcome, when setting up Dada Mail.
Use your local mail server/sendmail command to send mail
The easiest way to send mail with Dada Mail is to just use the local mail server on your hosting account, via the sendmail command, instead of using Google's SMTP servers. Your local mail server will have a different, but hopefully higher limitation, than the Google Apps limitation - hopefully 500 messages/hour and higher.
One possible problem with this method is that subscribers with email addresses belonging to your domain (and which have addresses administrated by Google Apps) will not receive messages sent by Dada Mail, since sending will be done to the local email account - which probably won't exist.
The only thing you want to make sure is set up correctly is the SPF record for sending email using your local mail server. How to do that is a little over the reach of this tutorial - but it may be that there's nothing you need to do, as its the Google Apps server that'll require the SPF record to be setup correctly.
Using Bridge for Discussion Lists
Method #1 Setup the List Email account on Google Apps, use the Google Apps login info
You'll probably be able to use Bridge with Google Apps, since Bridge only needs to be able to receive email, if like above, we're setting up Dada Mail to send using the local mail server.
You'll want to setup the List Email POP account through Google Apps and plug in the Login Info for this List Email into Bridge. A few things should be the same for all Google Apps email accounts, as is listed at:
For Bridge, this is broken down as:
List Email: firstname.lastname@example.org POP3 Server pop.gmail.com POP3 Username: email@example.com POP3 Password: (Password) Type: Automatic Use Secure Sockets Layer (SSL) CHECKED.
If Use Secure Sockets Layer (SSL) is disabled, you may be out of luck, until the missing CPAN modules are installed.
That's it. Mail will be received via Google Apps, sent using the local mail server and replies will be sent to the Google Apps POP3 List Owner email account.
Nothing to it.
Method #2 Setup a subdomain with a different MX record
Another option may be to just setup a separate subdomain and a different MX record, so that mail sent to an email address with this subdomain will simply be handled by your hosting account instead of Google Apps. This workflow works exactly like you'd work with Dada Mail, without Google Apps
Using Bounce Handler
Using the Bounce Handler may be tricky.
You'll want to use the local mail server, as before to send mail, but it's possible that the local mail server is also what's creating the bounced messages that is supposed to be delivered to the Bounce Handler Email address. Sometimes, this means, the local mail server will look for a local email box belonging to the bounce handler email address. If it can't find it, no bounced message will get delivered, even if you have the exact same email account setup correctly via Google Apps.
Method #3 Setup a local mailbox
One option is to simply setup that local mailbox and use the login info that points to your hosting account's mail server, instead of using Google Apps. This is a very strange setup, as you cannot send an email message to this mailbox, as you regularly would - it would just be checked via Google Apps, but it can be used locally by your local mail server to store the bounce messages, as well as by Bounce Handler to, check this local messages.
Method #2 Setup a subdomain with a different MX record
Just like with Bridge, another option would be just to set up a new subdomain, with a different MX record that points the subdomain's email delivery to your hosting account's mail server, instead of Google Apps.
Write an HTML message, receive it as PlainText
If you write your message in HTML, and it's received what looks like PlainText, a few things may be wrong:
Your mail reader doesn't support reading the message in HTML and will show the PlainText version of your message.
That's pretty easy to find out if that's true - if *all* messages you receive are plaintext, it may be a good chance that this is true.
Your mail reader is just showing you the PlainText version of the message you send out.
Dada Mail sends both a plain text and HTML version of the message which are both embedded in the email message itself - this is called a multipart/alternative message. Usually, the mail reader will pick the HTML version to show, but, depending on your preferences, it may show the plain text version
Something on your hosting account server is stripping the HTML version from your email message
In rare occassions, the mail server will actually strip out the HTML version of your email message, before it actually sends the message to your subscribers. You can try sending a test message in HTML that's extremely simple and see if it goes through and then, continually make a more complex message. It's possible that a specific character is triggering this
No Mail is Sending at All.
List Owner/List Administrator set up Correctly?
One common problem we see is that someone will set up the List Owner, or List Administrator to an address that the mail server will not accept mail from.
Usually, this happens when the List Owner/Administrator address isn't from an address that's hosted on the account. So, for example if my site is,
mysite.com, setting the List Owner/Administrator to an address from my account, example:
firstname.lastname@example.org should work fine, provided:
That account exists
Make sure the account you're using already exists. Mail systems that accept mail sometimes look up email accounts that exist. If the account for your List Owner/Admin does not, your message may not be accepted.
That account is not a mail forward
Sometimes, the mail system's check to see if an email account exist doesn't cover mail forwards that are valid and do exist, so even if you use a valid mail forward as your List Owner/Admin, things still won't work correctly.
That account is not disabled in some way
Sometimes valid email accounts have mail sending disabled because of a variety of reasons: too many messages being sent, too may bounces being sent back, over an disk quota, etc. Make sure these issues are cleared up and always check the List Owner address and if you're using a separate List Administrator address, have it properly set up with Bounce Handler.
Using an email address from a third party email service, like Hotmail, Gmail, Yahoo! Mail, etc is not advised.
Set your $MAILPROG to a file, instead of piping to sendmail
Adding the following lines to your
$MAIL_SETTINGS = '>> /home/account/.dada_files/.tmp/mail.txt'; $MASS_MAIL_SETTINGS = '>> /home/account/.dada_files/.tmp/mail.txt';
/home/account/.dada_files is the path to your own
When your mailing list preferences are set to use sendmail to send out messages, messaages will instead just be appended to the file, in the location above. You can then manually inspect the output of what Dada Mail is creating to spot any problems.