homepage Welcome to WebmasterWorld Guest from 54.197.108.124
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Pubcon Platinum Sponsor 2014
Visit PubCon.com
Home / Forums Index / WebmasterWorld / Webmaster General
Forum Library, Charter, Moderators: phranque & physics

Webmaster General Forum

    
Email Optimization Consultant - The New Marketer
pageoneresults




msg:342235
 7:16 am on Apr 7, 2006 (gmt 0)

EOC - Email Optimization Consultant

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.

 

henry0




msg:342236
 11:33 am on Apr 7, 2006 (gmt 0)

Thank you
A while ago I reviewed SPF and then forgot about it

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!

MaxMaxMax




msg:342237
 12:56 pm on Apr 7, 2006 (gmt 0)

This is a mammoth topic. But for the record, here are some other popular services doing something similar to Goodmail:

Return Path's Bonded Sender...
[bondedsender.com...]

Habeas
[habeas.com...]

ISIPP
[isipp.com...]

moishe




msg:342238
 1:49 pm on Apr 7, 2006 (gmt 0)

I work for a VERY LARGE ISP, (Brett can verify this), and the number one problem that I see with people sending mail from private domains, (IE yourdomain.com), is bad PTR records. (PTR record is reverse lookup information, whoever provides the IP address of your domain will settup the PTR record for you)

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...

Chico_Loco




msg:342239
 1:54 pm on Apr 7, 2006 (gmt 0)

Very interesting. I just read the domainkeys solution and it seems promising, at least for domain authentication.

Question: Does Yahoo or anyone else currently check this, or is it just a proposed technology?

Chico_Loco




msg:342240
 2:19 pm on Apr 7, 2006 (gmt 0)

When you say "bad PTR's"... do you mean that the PTR should contain the domain name of the the domain in the FROM: field?

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.

moishe




msg:342241
 2:42 pm on Apr 7, 2006 (gmt 0)

The PTR issue is usually an issue with non-shared IP's.

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.

NickCoons




msg:342242
 2:45 pm on Apr 7, 2006 (gmt 0)

<When you say "bad PTR's"... do you mean that the PTR should contain the domain name of the the domain in the FROM: field?>

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.

pageoneresults




msg:342243
 2:46 pm on Apr 7, 2006 (gmt 0)

Running a DNS Report on your mailserver will alert you to any potential issues that you may have.

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.

StupidScript




msg:342244
 5:16 pm on Apr 7, 2006 (gmt 0)

With the exception of Habeas (which is a cool idea, but has gone down the wrong roads a few times .. but it's still cool), the current crop of programs all depend on a "valid" message coming from a "trusted" server.

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.

StupidScript




msg:342245
 5:18 pm on Apr 7, 2006 (gmt 0)

With the exception of Habeas (which is a cool idea, but has gone down the wrong roads a few times .. but it's still cool), the current crop of programs all depend on a "valid" message coming from a "trusted" server.

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.

jchance




msg:342246
 5:08 am on Apr 8, 2006 (gmt 0)

Having receintly gone through this pain of getting our company's mail past the yahoo, msn, gmail, aol, spam filters, I can provide some info.

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.

KanukBoy




msg:342247
 7:57 am on Apr 8, 2006 (gmt 0)

Uhmm... What am I missing here? Why is it so complicated?

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?

KanukBoy




msg:342248
 8:06 am on Apr 8, 2006 (gmt 0)

Oh and let me add...

No sending fees!

henry0




msg:342249
 11:52 am on Apr 8, 2006 (gmt 0)

I am still missing something:
I cannot figure what's happening after implementing SPF server side.

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.

jchance




msg:342250
 2:21 pm on Apr 8, 2006 (gmt 0)

henrey:

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?

henry0




msg:342251
 2:33 pm on Apr 8, 2006 (gmt 0)

AHHH,
Now I got it!

Thanks for the guided visit :)

Henry

pageoneresults




msg:342252
 8:10 am on Apr 9, 2006 (gmt 0)

Wow! If all of this is happening while we are asleep, we're in trouble. Hopefully those of you involved with email marketing are keeping up with all of this. After MaxMaxMax posted their additional Trusted Email programs, I decided to do some price comparisons. Are you ready for this? Get your checkbooks out...

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.

coopster




msg:342253
 11:05 am on Apr 9, 2006 (gmt 0)

Looks like MaxMaxMax has been doing some homework ;-)
The list provided from MaxMaxMax is the very same Sender Policy Framework (SPF) [webmasterworld.com] list of Accreditation Services (link is in message #6).

MaxMaxMax




msg:342254
 3:51 pm on Apr 9, 2006 (gmt 0)

No homework needed ;-), just happen to work in the business (on the media side) and have contacts with all of the companies involved (bar Goodmail).

elklabone




msg:342255
 4:10 pm on Apr 25, 2006 (gmt 0)

I inquired with Habeas about their services. They called me today and told me that their services start at $3,000.

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.

pageoneresults




msg:3318918
 3:09 pm on Apr 23, 2007 (gmt 0)

I've had this topic "resurrected" so I could share some findings of mine over the past year in regards to Trusted Email.

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

bill




msg:3319606
 4:32 am on Apr 24, 2007 (gmt 0)

DKIM - DomainKeys Identified Mail

After reading a lot of your ideas last year I was looking to implement DomainKeys on one of my servers. However I found it very difficult because none of the big mail transfer agents like Exim or Sendmail even had plug-ins available. I'm still not sure whether there are many release candidate level implementations out yet. I put my project on a back burner to wait until the software options became available.

Is there anything the average webmaster can implement on his server today other than SPF?

henry0




msg:3319840
 11:20 am on Apr 24, 2007 (gmt 0)

I believe that since a while our “Web instinct” has somehow forecasted the mail optimizer new job description arrival!

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!

Global Options:
 top home search open messages active posts  
 

Home / Forums Index / WebmasterWorld / Webmaster General
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved