Forum Moderators: phranque
There's a new breed of marketer being born. The Email Optimization Consultant. While many of us have been busy with the plethora of marketing products and services that we offer, two of the biggest ISPs are making drastic changes to the way email is being handled. The new industry buzzword is Trusted Email.
Based on everything I've been reading and researching, the following is a checklist of strategies that the EOC should be familiar with. In addition, assistance in setting this up for the client will set you apart from the others. Understanding and being able to implement the following protocols will give you the edge over the competition. So, here's the roundup...
SPF - Sender Policy Framework
[openspf.org...]
What is SPF? SPF (Sender Policy Framework) fights return-path address forgery and makes it easier to identify spoofs. Domain owners identify sending mail servers in DNS. SMTP receivers verify the envelope sender address against this information, and can distinguish authentic messages from forgeries before any message data is transmitted.
Yahoo! DomainKeys
[antispam.yahoo.com...]
DomainKeys is a technology proposal that can bring black and white back to this decision process by giving email providers a mechanism for verifying both the domain of each email sender and the integrity of the messages sent (i.e,. that they were not altered during transit). And, once the domain can be verified, it can be compared to the domain used by the sender in the From: field of the message to detect forgeries. If it's a forgery, then it's spam or fraud, and it can be dropped without impact to the user. If it's not a forgery, then the domain is known, and a persistent reputation profile can be established for that sending domain that can be tied into anti-spam policy systems, shared between service providers, and even exposed to the user.
AOL Whitelist
[postmaster.aol.com...]
The AOL whitelist is designed to help America Online work with organizations and individuals who send out solicited bulk email.
Goodmail
[goodmailsystems.com...]
The Goodmail CertifiedEmail service offers legitimate, accredited senders the opportunity to assure their messages are reliably delivered and presented to consumers as authentic and safe to open. The CertifiedEmail service is available to reputable, responsible organizations for a small per-message fee.
AOL and Yahoo! have partnered with Goodmail Systems to provide a safe and reliable class of email - the CertifiedEmail service.
Current Home Page Topic - AOL CertifiedMail
[webmasterworld.com...]
Yes, it has gotten to the point where email is now a major marketing issue. Particularly for those who use AOL, Yahoo!, Hotmail and other large ISPs. It won't be long before the other majors adopt the Goodmail or similar Trusted Email program.
Does this concern you? Are you prepared to assist your clients in managing their email and developing a Trusted Email environment?
Have I missed any others? They appear to be cropping up rather quickly. I would imagine the hot new stocks will be Trusted Email providers. Goodmail appears to have a strong following so far.
So I first checked if it will work with my dedicated server -since I do not manage my DNS-
Got this from my ISP
<<<
If you have a specific SPF record you would like added the administrators can add it for you
>>
Now how can I implement it
I think I need to get a SPF record per DN?
but then how do I implement it for my own domain and for my other clients' account.
(I use only fixed IPs and no shared IPs)
The concept I get, the implementation I don't!
Return Path's Bonded Sender...
[bondedsender.com...]
Habeas
[habeas.com...]
ISIPP
[isipp.com...]
When setting up domains for yourself and for clients it is absolutely essential that the PTR records are settup properly to avoid having mail rejected from the mail servers of large ISP's.
Of course, if you are doing bulk, unsolicited email and you get yourself on some black hole lists, (spammer lists), proper reverse lookup info is not gonna make any difference...
Question: Does Yahoo or anyone else currently check this, or is it just a proposed technology?
My mail is sent for the main server, which also hosts the site mysite.com... mail is sent with a FROM: of mail@mysite.com. My MX record (mail.mysite.com) points to another server which handles inbound mail, and it uses a different domain - so if I do a reverse lookup on mail.mysite.com (which is my MX record) it's PTR is someothersite.com and not mysite.com - is that a problem?
I had to do it that was because email is a nightmare to set up, so I used sendmail on my system to send, but a 3rd party to handle inbound mail management.
If you are on a shared IP, the PTR will resolve to the actual host and this will only be a problem if that host gets banned.
If your (or your clients) domain has its own IP, this is usually where the issue comes up.
I will include a link from the security page of a major ISP that will allow you to check the status of the reverse lookup of your IP, I don't know if the MODS will want to snip it, but it is very handy.
[security.rr.com...]
In the DNS Reverse (i.e., PTR record) Lookup, what you do not want to see is 'NXDOMAIN' or 'SERVFAIL', what you do want to see is your domain or your host providers domain.
I don't think that would be a problem (at least, I can think of legitimate reasons why it shouldn't be), and I know a lot of systems that are setup that way.
The most common problem that I run into in this regard is that there is no PTR record, so no reverse DNS is possible.. and some mail servers will reject mail based on this. I can't believe there are some rather major ISPs out there that don't, by default, reverse-resolve their IP addresses to at least something.
DNS Report [dnsreport.com]
PASS
Reverse DNS entries for MX records OK.
The IPs of all of your mail server(s) have reverse DNS (PTR) entries. RFC1912 2.1 says you should have a reverse DNS for all your mail servers. It is strongly urged that you have them, as many mailservers will not accept mail from mailservers with no reverse DNS entry. Note that this information is cached, so if you changed it recently, it will not be reflected here (see the www.DNSstuff.com Reverse DNS Tool for the current data). The reverse DNS entries are:
Under the MX Records portion of the report, you'll want to make sure you receive a pass on the above PTR issues. The number of sites that fail for this is rather large. But, you have to be sure that you are running the report on the domain/IP that mail is being sent from.
So:
1) Example.com is validated by any/all of the services.
This means that mail originating from a "valid" user at that domain will be "trusted".
2) Spammer sends mail through "mail.example.com" as "jane" (a known valid, roaming user)
What happens to that mail? Let's see ... valid user, trusted domain ... bingo!
As far as they can tell, the SPF/PTR records are cool, the domain is in the receiving whitelist and the sending server sure didn't complain that "jane" was using it to send a message.
Solutions on the sending end, like SMTPAuth or some other use-name-and-password-for-every-send method, seem to be the most likely to actually work consistently.
Anybody want to take a shot at how we can educate every email-using individual to log in and give their password for each message they want to send? Heck, it's hard enough getting users to CHECK their messages regularly, let alone force them to use some cryptic procedure to get their mail out.
So:
1) Example.com is validated by any/all of the services.
This means that mail originating from a "valid" user at that domain will be "trusted".
2) Spammer sends mail through "mail.example.com" as "jane" (a known valid, roaming user)
What happens to that mail? Let's see ... valid user, trusted domain ... bingo!
As far as they can tell, the SPF/PTR records are cool, the domain is in the receiving whitelist and the sending server sure didn't complain that "jane" was using it to send a message.
Solutions on the sending end, like SMTPAuth or some other use-name-and-password-for-every-send method, seem to be the most likely to actually work consistently.
Anybody want to take a shot at how we can educate every email-using individual to log in and give their password for each message they want to send? Heck, it's hard enough getting users to CHECK their messages regularly, let alone force them to use some cryptic procedure to get their mail out.
SPF - This is critical, especially for gmail and yahoo. Microsoft has a "Sender ID" (of course, microsoft has to rename it right) creation tool that you can use to generate your spf record:
[microsoft.com...]
DomainKeys - I was never able to find any useful info on implementing it with exim. If someone has info, I would love to see it. I was able to get by the Yahoo spam filters without it, so I guess if they are using it, obviously its just a piece of their spam system.
However, in order to get past the yahoo spam filter I had to contact yahoo directly. Goto: [postmaster.yahoo.com...] where you can fill out a long form promising to be good.
RDNS - This is critical. Without it, you won't get past any spam filters. Your hosting company will have to set this up for you.
There is a mechanism to check for Sender spoofing, such as SPF, right?
Then, all that needs to be done is the receiver of the solicited email tell her ISP to whitelist emails from the domain where she has just subscribed. This can all be done automatically and verified by the user with a post back to the ISP.
Example:
I run a site about widgets where visitors can subscribe to email newsletters. Jane who uses AOL, visits my site and signs up for my newsletters. After jane submits her email address to me, I post to a special page at AOL that AOL has set up for this purpose. I post to the AOL page:
- Jane's AOL email address
- My domain name
- The email address(es) I will be using to send solicited emails and perhaps an address I will be using for support purposes, e.g. newsletter@widgets.com and support@widgets.com.
Jane logs in with her AOL username and password. Jane verifies the posted information and clicks on a big fat Allow Sender button.
AOL then whitelists emails that are verified to be from newsletter@widgets.com and support@widgets.com and are destined for Jane. No need for spam lists, filters, etc.
The end user has the last word. No falsely rejected legit emails.
Why won't this work?
No sending fees!
Example:
I have a DN for a client named aa.com
and I have a few email addresses tied to the name
such as joe@aa.com
So for my understanding I need to figure if joe has any task to perform on the machines he uses?
And does that change the way any mailer are sending mail to joe from allover the world?
Thanks
BTW the MS link is a good beginning although it does not provide an answer to my questions.
After creating your SPF record, you have to add the SPF text to your DNS record for aa.com. Usually your hosting company has to do this for you. What happens is this:
1. Joe at aa.com sends an email to friend@hotmail.com from his server aa.com (IP address 192.168.1.1)
2. hotmail.com receives the email and see that it came from aa.com. It checks aa.com's SPF record and sees that 192.168.1.1 is listed as a valid IP address for aa.com.
3. The mail is allowed.
It doesn't change anything regarding inbound mail to aa.com.
ALSO: When creating your SPF (Sender ID) record, remember that you have to list ALL places where email might originate from. For example, when sending mail from my PC for my business, I send all of my email through my ISP's SMTP server. So not only do I have to list my domain's IP addresses as valid source locations for emails, I also have to add my ISP's IP address.
More confused yet?
Thanks for the guided visit :)
Henry
Goodmail Systems CertifiedMail
Application Processing Fee
- $399.00
Token Rates (as low as $2.50 per thousand emails)
- $0.0025 per email
ESPs (Email Service Providers) will need to purchase the Goodmail Appliance (PowerMTA or StrongMail) in addition to the above costs.
Bonded Sender Program
Non Profit - Max 1,000,000 email messages per month
Application Fee
- $400.00
Annual License Fee
- $0
Bond
- $250.00
Commercial - Max 500,000 email messages per month
Application Fee
- $400.00
Annual License Fee
- $1,000.00
Bond
- $500.00
Note: Additional tiers available and pricing does increase quite a bit with max numbers at...
Commercial - Unlimited (Bulk Email)
Application Fee
- $1,500.00
Annual License Fee
- $20,000.00
Bond
- $4,000.00
Habeas for Senders
2006-04-09T01:08:00-0700 - The Habeas site has been down since I've been performing the pricing research. Once it is back up, I'll get that data and append this topic.
ISIPP aka IADB
Newsletter Publishers
Publishes hobby newsletters, not a corporate or online business
- $10.00 per month
Non-Bulk Corporate Mailers
Sends only transactional and business correspondence, no mailing lists or other bulk email
- $100.00 per month
Bulk Corporate Mailers
Sends their own incidental bulk mail such as in-house newsletters; Internet communications is not part of their primary business model
- $150.00 per month
Commercial Primary Mailers
Sends bulk email or other Internet communications as part of business model; does not send email on behalf of customers
- $200.00 per month
Email Marketing and Campaign Providers
Sends email on behalf of customers (fewer than 30 customers)
- $200.00 per month
Email Marketing and Campaign Providers
Sends email on behalf of customers (30 or more customers)
- $300.00 per month
Non-Refundable Application Fee
Includes all background, reference, and other checks
- $500.00
The cost of doing business just got a bit more expensive.
But, you'll need to compare that with the cost of lost business due to your emails not being received.
I think they're going to give us a demo early next week (first week in May, 2006), so maybe I'll follow-up with more information about them for posterity.
I've been following the progress of financial institutions and how they are handling their email. I figure if there is one user group out there that needs to continually maintain the integrity of its communications, its financial institutions.
I just read a white paper from the BITS Financial Services Roundtable. In that white paper much of what I discussed in this topic and others is being implemented along with some additional layers I'd not heard of before until now.
TLS - Transport Layer Security
DKIM - DomainKeys Identified Mail
I'm not going to go too far into depth in regards to the above. Here's a link to the white paper. I printed it and have read it multiple times. I'll read it again multiple times until I fully understand what they (financial services) are up to. :)
[bitsinfo.org...]
For those of you following this topic, are you, or do you plan to implement these types of security features within your email network?
I see an industry growing rapidly and that is third party email providers who have developed and established a Trusted Email network that allows them to guarantee delivery of your email. Anyone using this type of arrangement for their primary mail?
P.S. Another initialism to add to the mix...
ESP - Email Service Provider
DKIM - DomainKeys Identified Mail
Is there anything the average webmaster can implement on his server today other than SPF?
I will diverge a bit from the main topic:
I now consider the email system as a vector not being reliable and too costly the professional services. To me it’s a lost war; recoup and move in another direction.
We really should focus on other delivery means
For example web notification and/or
Utilizing a very personalized envelope that clearly states where it comes from and what it is the included topic.
I am really advising some clients to go back to that form of straightforward mail!
