MailEnable Pro 1.5 beta -- GREAT GOING!

Discussions on webmail and the Professional version.
Post Reply
fmaxwell
Posts: 151
Joined: Sat Aug 03, 2002 9:10 am

MailEnable Pro 1.5 beta -- GREAT GOING!

Post by fmaxwell »

I've been using MailEnable Pro 1.5 beta and am thrilled with it! Two VERY important features have been added:

1. Blocking email addresses at the SMTP service -- This means that you can have a catch-all account and still block addresses that spammers hit. I've put in about a dozen already and it's working great, giving 550 errors and probably getting the addresses auto-purged from spam lists as a result.

2. SPF support. Not nearly enough domains have SPF records yet, but this will become more useful as more domains invest the 15 minutes it takes to create them. Plus, it tells you when domains don't have SPF records so that you can harass their postmasters about it. :D

The MailEnable team really did the blocking the right way: They check to see if the recipient address is blocked before checking against the DNS blacklists. That saves time as well as giving the 550 error, which tells the spammers that the address is not live. A block due to a blacklist leaves the spammers trying since they hope to get through next time from a different IP address.

MartynK
Posts: 1376
Joined: Sat Dec 28, 2002 1:12 am
Location: Hong Kong

Post by MartynK »

I would like to agree with the previous email.

I have been running the Beta since release and it seems to run like a dream. I am currently testing a new version of MEFilter with extra code for SPF and so far it seems to be getting it correct all of the time.

It has been a version worth waiting for, as once again we seem to be ahead of rival mail software in getting functionality.

jorune
Posts: 174
Joined: Fri Jul 02, 2004 5:05 pm
Location: Chicago, IL

Re: MailEnable Pro 1.5 beta -- GREAT GOING!

Post by jorune »

fmaxwell wrote:1. Blocking email addresses at the SMTP service -- This means that you can have a catch-all account and still block addresses that spammers hit. I've put in about a dozen already and it's working great, giving 550 errors and probably getting the addresses auto-purged from spam lists as a result.
That does sound great! I'm running 1.2 currently which is handling 80 domains and about 450 mailboxes and wouldn't' feel comfortable installing an official beta release, but I look forward to the final release.
2. SPF support. Not nearly enough domains have SPF records yet, but this will become more useful as more domains invest the 15 minutes it takes to create them. Plus, it tells you when domains don't have SPF records so that you can harass their postmasters about it. :D
How, out of curiosity, would you go about setting up an SPF record? I've never worked with the SPF protocol and if anyone wouldn't mind sharing some info would be great!

fmaxwell
Posts: 151
Joined: Sat Aug 03, 2002 9:10 am

Re: MailEnable Pro 1.5 beta -- GREAT GOING!

Post by fmaxwell »

jorune wrote:How, out of curiosity, would you go about setting up an SPF record? I've never worked with the SPF protocol and if anyone wouldn't mind sharing some info would be great!
An SPF record is simply a text record in DNS. The easiest way to formulate the record is to go to http://spf.pobox.com/, use their "wizard" and let it step you through the process. Here are a couple of examples:

"v=spf1 ip4:10.123.456.789 -all" -- That is a simple one saying all mail for the domain comes from one IP address of 10.123.456.789.

"v=spf1 mx -all" -- That says that only your MX hosts are allowed to send mail for your domain. That's probably going to fit your domains since MailEnable both sends and receives.

It is very much in your interest to create SPF records. Suppose that some spammer decided to blast AOL with spam purporting to be from one of your users/domains. With an SPF record, AOL would be able to recognize that the sender was not from your domain and block the e-mail before it ever got into their system. Without that, you'd have to deal with complaints, bounces, etc. Take it from someone who has alread been a "joe-job" victim; it's not fun.

Your mail server does not need to support SPF for you to implement an SPF record. The SPF record tells others with SPF-aware servers what servers are permitted to send e-mail for addresses under your control. When you get an SPF-aware version of MailEnable, you will be able to perform the incoming checks, but it's valuable to you and your customers to have records now so that spam forged from your domains can be rejected.

One word of warning: You must make your users aware of SPF and how it will affect them. I recommend something like:

"We will be implementing SPF (Sender Policy Framework) records to protect our users on {insert date here}. As of that time, all outgoing mail with an address we provide will have to go through our servers or risk being bounced by the recipient's server.

An SPF record identifies the permitted sending mail servers (in DNS) for your domain. Receiving servers can verify the sender address against that information. That allows them to reject spam, viruses, and worms hich have forged addresses from your domain.


Basically, you don't want them to use the SMTP server at their work, college, etc. to send while using an address that you provide. Otherwise the e-mail will be rejected by SFP-aware SMTP servers.

jorune
Posts: 174
Joined: Fri Jul 02, 2004 5:05 pm
Location: Chicago, IL

Re: MailEnable Pro 1.5 beta -- GREAT GOING!

Post by jorune »

fmaxwell wrote:It is very much in your interest to create SPF records. Suppose that some spammer decided to blast AOL with spam purporting to be from one of your users/domains. With an SPF record, AOL would be able to recognize that the sender was not from your domain and block the e-mail before it ever got into their system. Without that, you'd have to deal with complaints, bounces, etc. Take it from someone who has alread been a "joe-job" victim; it's not fun.
Yes several of my domains have been "joe-job" victims. Most recently my main domain coastaldatalink.net has been subject to this abuse with AOL sending my postmaster account rejected mail. Which is why the SPF protocol has interested me.
Basically, you don't want them to use the SMTP server at their work, college, etc. to send while using an address that you provide. Otherwise the e-mail will be rejected by SFP-aware SMTP servers.
Okay, now this is the problem. I run a web hosting company (albeit small) with 80 domains and about 450 mailboxes on MailEnable server. Basically clients host their company websites with me and like to have email at their domain (i.e. jane@mycompany.com) which, of course, I provide for them with their hosting account. Many of them check their mail using webmail - which is great, but many of them like using Outlook Express or some other POP client. Since it's cumbersome to add relay rights for everyone that wants to send mail using their domain name (i.e. jane@mycompany.com) I usually instruct them to use their ISP's mail servers to send mail.

Before you yell at me, mind you the POP before authentication was not available in MailEnable until very recently (I think 1.19 or 1.2 version). In other words, I couldn't possibly add privileged IP addresses for every customer that wanted to relay off the server, hence why I told them to use their own ISP SMTP servers. And even still, the POP before authentication rule could - in some cases lead to customers getting their outgoing mail bounced by the server should the timeout expire.

Try to understand I'm dealing with small to medium sized customers that know little about computers and just like to look at their business website and check their mail. If I were to send out a notice to all of them about a new SPF rule going into place, well, that would simply confuse them. :roll:

I guess the best course of action for me is to protect my company domains (like coastaldatalink.net) and force my employees and contractors that use that domain to relay off my server. At least I can start there. As for my customers, I can work with them on a case by case basis. I presume I would have to generate an SPF record for each domain that lives on the server.

In any case, thanks for the information and the instructions on how to go about setting up SPF records. Big help!

-Johnny
Windows 2003
MailEnable 1.2

fmaxwell
Posts: 151
Joined: Sat Aug 03, 2002 9:10 am

Re: MailEnable Pro 1.5 beta -- GREAT GOING!

Post by fmaxwell »

jorune wrote:
Basically, you don't want them to use the SMTP server at their work, college, etc. to send while using an address that you provide. Otherwise the e-mail will be rejected by SFP-aware SMTP servers.
Okay, now this is the problem. I run a web hosting company (albeit small) with 80 domains and about 450 mailboxes on MailEnable server. Basically clients host their company websites with me and like to have email at their domain (i.e. jane@mycompany.com) which, of course, I provide for them with their hosting account. Many of them check their mail using webmail - which is great, but many of them like using Outlook Express or some other POP client. Since it's cumbersome to add relay rights for everyone that wants to send mail using their domain name (i.e. jane@mycompany.com) I usually instruct them to use their ISP's mail servers to send mail.

Before you yell at me, mind you the POP before authentication was not available in MailEnable until very recently (I think 1.19 or 1.2 version).
Now can I yell at you? ;-)

On my domains, I simply require authentication for SMTP. Not POP-before-SMTP authentication -- plain old authentication. That means that the user has to supply the same login and password to the SMTP server as to the POP3 server. For those using Outlook, it's as simple as checking two boxes to enable:

[ ] My outgoing (SMTP) server requires authentication
[ ] Use same settings as my incoming mail server
In other words, I couldn't possibly add privileged IP addresses for every customer that wanted to relay off the server, hence why I told them to use their own ISP SMTP servers. And even still, the POP before authentication rule could - in some cases lead to customers getting their outgoing mail bounced by the server should the timeout expire.
I think that the normal method of authentication that I mentioned will solve that.
I guess the best course of action for me is to protect my company domains (like coastaldatalink.net) and force my employees and contractors that use that domain to relay off my server. At least I can start there. As for my customers, I can work with them on a case by case basis. I presume I would have to generate an SPF record for each domain that lives on the server.
Yes, you would have to create an SPF record for each, though they would all be the same (probably "v=spf1 mx -all").

You're better off doing it now than later. As SPF becomes more and more accepted, domains will start using it to bypass more annoying and failure-prone spam checks like greylisting (delayed acceptance of e-mail), content-filtering, etc. If your customer domains don't have SPF, then their e-mail will be treated as second class, where its delivery may be delayed or it might be more likely to be "quarantined."

There is also the issue of more and more ISPs requiring that the outgoing "From:" address match their domain. As someone who works for an ISP wrote:
"We have never permitted outgoing mail to be sent from our mail servers which doesn't contain a 'From' address matching a valid e-mail account on our system. There are two simple solutions for your subscribers for whom this is an issue. Tell your subscriber to send his outgoing mail through the mail server provided by his other domain. If that host doesn't provide e-mail services, suggest that your subscriber consider hosting his site at your facility. Alternatively, tell your subscriber to use an e-mail address matching a valid mailbox hosted on your system as their 'From' address, then to place the address to which they'd like replies to be sent in the 'Reply To' box. Their correspondents will never notice. If you permit folks to send outgoing mail through your servers using a bogus 'From' address, you're asking for trouble."
You're better off walking your customers through this now rather than dealing with it later as their ISPs start blocking mail with non-matching "From:" addresses.

jorune
Posts: 174
Joined: Fri Jul 02, 2004 5:05 pm
Location: Chicago, IL

Post by jorune »

Okay I just sent this out to my resellers list. This will hopefully start the process of bringing customers "in house" so to speak when they are sending mail. I just enabled "Allow relay of authenticated senders" on the server - somehow that option escaped my feeble mind.
Sent to our resellers list:

Subject: Relaying now available on CoastalDatalink.NET
To: CoastalDatalink.NET resellers


Hello,

I have, as of today, enabled "Allow relay of authenticated senders" on our mail server. This means that if you have a valid email account on the server, you can relay off the server as long as you setup your email client to supply your mail login credentials. Up until now CoastalDatalink.NET was only allowing privileged IP addresses to relay off our server due to the problems associated with SPAM organizations that routinely take advantage of what is known as an "open relay server".

In an effort to help further protect our customers from spam we are going to begin the process of implementing the SPF protocol. SPF: Sender Policy Framework is a relatively new Anti-Forgery solution that is making the world a safer place for email. I won't go into great detail here, but if you are interested in more information about how this protocol works please see this link:

http://spf.pobox.com/howworks.html

Basically it's a way to help protect our domains (and our customers domains) from being "forged" or "spoofed" by spammers. Spammers routinely use an existing domain that is not under their control and "pretend" to send mail from it. The headers look like it came from a domain that did not, in fact, send the spam message. This is problematic for several reasons because ISP such as AOL, for example, will "think" that your domain was responsible for the spam and will take measures to stop the problem. This means that legitimate mail inbound for AOL could be rejected.

So how does "Allow relay of authenticated senders" tie in with the SPF solution? Well, the problem is that SPF aware mail servers will be checking to make sure that mail you send on behalf of your domain(s) are, in fact, coming from an authorized mail server. Meaning if you send your mail as jane@mydomain.com to AOL for example, the AOL server will do an SPF check and make sure that your headers are, in fact, coming from the server that is responsible for mydomain.com.

I hope this makes sense, and it can be very confusing. I'm sending this to the resellers list because I wanted to let them understand what is happening. CoastalDatalink.NET will NOT be setting up the SPF records right away. First we want to try and get our customers to start using the server to SEND mail on behalf of their domains. The current mindset until now was to have them use their ISP SMTP servers to send mail and so we are in a bit of a predicament. If we were to suddenly turn on SPF a lot of customers might begin to have trouble sending mail to SPF aware mail domains.

Therefore, we need to change our policy of having customers use their local ISP SMTP servers to send mail. Instead by having them setup their mail clients to authenticate on the CoastalDatalink.NET server using the same login and passwords they would use to check mail. Hopefully after doing this we can then slowly start to implement the SPF protocol on domains that are "brought in house" so to speak. A final note: Users that are currently using Webmail to check and send mail will NOT be affected by this.

All this is being done in an effort to help our customers use mail safely and effectively. If you have any questions please do not hesitate to contact me.

Johnny Heintz / Director Network Operations
CoastalDatalink.NET
Chicago Data Center
Last edited by jorune on Fri Oct 22, 2004 12:50 pm, edited 1 time in total.

jorune
Posts: 174
Joined: Fri Jul 02, 2004 5:05 pm
Location: Chicago, IL

Post by jorune »

fmaxwell wrote:Now can I yell at you?
YES! I'm a tard! :oops:

fmaxwell
Posts: 151
Joined: Sat Aug 03, 2002 9:10 am

Post by fmaxwell »

jorune wrote:
fmaxwell wrote:Now can I yell at you?
YES! I'm a tard! :oops:
No, you're a decent guy doing the right thing -- even though it will cause a little pain in the short term. Thanks.

fmaxwell
Posts: 151
Joined: Sat Aug 03, 2002 9:10 am

Post by fmaxwell »

jorune wrote:Okay I just sent this out to my resellers list. This will hopefully start the process of bringing customers "in house" so to speak when they are sending mail. I just enabled "Allow relay of authenticated senders" on the server - somehow that option escaped my feeble mind.
That was a well-crafted letter and I think that it makes the whole process a lot easier to follow. The one thing that you may want to mention in future communications is the restriction by many ISPs that e-mail sent through their servers have sender addresses on their servers. This is going to make it impossible for many customers to use their ISP's servers to send e-mail "from" their personal domains.

paarlberg
Posts: 1071
Joined: Tue Mar 02, 2004 7:33 pm
Location: Atlanta, GA, USA

Post by paarlberg »

That was a good letter. I have also done the same thing to all of our hosted domains as well by making them aware that we are using SPF and I have updated their domains for them. I have also implemented SPF filtering with MEFilter 4.0 which is currently only marking e-mails (SPF FAIL) that are sent from bogus mail servers. It is quite interesting to see how many are from unauthorized mail servers.

To simplify management of the SPF records on each domain, I have created an entry in my DNS zone for my servers and then reference my entries in each hosted domains DNS zone.

"v=spf1 include:mydomain.com mx -all"

Should they want to send mail via another server, I can always change it to the following.

"v=spf1 ipv4:1.2.3.4/30 include:mydomain.com mx -all"

This will give them the ability send via webmail on our servers or via a local relay. This would be on a case by case scenario.

BTW: Is their a limitation to the number of IP addresses that can be referenced in the SPF record? If not, it would be very easy to add large groups of IP addresses to fool any SPF checking. This would be an easy way for spammers to ruin the SPF protection.

Kiliman
Posts: 279
Joined: Mon Feb 03, 2003 2:44 pm
Location: Chesapeake, VA

Post by Kiliman »

paarlberg wrote:This would be an easy way for spammers to ruin the SPF protection.
One of the benefits that SPF provides is that it links the IP address to the domain sending the email. This now allows you to do domain level blacklisting with more confidence.

I believe that as SPF gains in popularity, you will start to see these domain blacklists. These should be much better than IP-based RBL because it is more granular.

Kiliman

Shadow

Post by Shadow »

fmaxwell wrote:
jorune wrote:Okay I just sent this out to my resellers list. This will hopefully start the process of bringing customers "in house" so to speak when they are sending mail. I just enabled "Allow relay of authenticated senders" on the server - somehow that option escaped my feeble mind.
That was a well-crafted letter and I think that it makes the whole process a lot easier to follow. The one thing that you may want to mention in future communications is the restriction by many ISPs that e-mail sent through their servers have sender addresses on their servers. This is going to make it impossible for many customers to use their ISP's servers to send e-mail "from" their personal domains.
And what happens when you have an ISP that REQUIRES all outbound mail to go through their smtp servers? (Charter is a good example.) I can not send an email from home, where I have Charter, without sending it through their smtp server.

jorune
Posts: 174
Joined: Fri Jul 02, 2004 5:05 pm
Location: Chicago, IL

Post by jorune »

And what happens when you have an ISP that REQUIRES all outbound mail to go through their smtp servers? (Charter is a good example.) I can not send an email from home, where I have Charter, without sending it through their smtp server.
Good question - one which I thought about myself. As it seems the new "trend" is for ISPs to block port 25 thus forcing users to only use their SMTP service. This combined with restrictions on using alternate domains other than approved domains of the ISP locks you in pretty hard.

So you have to open another SMTP port on the mail server that you want to relay off of. Fortunately MailEnable supports dual SMTP listening (i.e. the second port could be on 26, for example).

Then you have to explain to customers (like in my case) that they need to relay off my server to use their domain name in the From: and they must use SMTP authentication and they must use a mail client that supports alternate SMTP port.... whew!

Not a pretty scenario.

fmaxwell
Posts: 151
Joined: Sat Aug 03, 2002 9:10 am

Post by fmaxwell »

jorune wrote:Then you have to explain to customers (like in my case) that they need to relay off my server to use their domain name in the From: and they must use SMTP authentication and they must use a mail client that supports alternate SMTP port.... whew!
Fortunately, almost all mail programs support alternate ports and SMTP authentication. But I agree that explaining it to customers isn't always easy. I suggest going to competing services like pobox.com and reading their documentation for examples of how they explain it -- since they face the exact same issues.

Post Reply