วันอังคารที่ 23 กุมภาพันธ์ พ.ศ. 2553
Why is hotmail Blocking/Junking my mail?
Because of Hotmail's extremely aggressive spam protection policies, senders may find valid emails being sent directly to recipient's junk folder or being blocked outright.
Below is the standard response send from Hotmail support regarding this issue. The only way to remove yourself from Hotmail's block list is to work with the steps listed below:
Hello,
We have identified that messages from your IP are being
filtered based on the recommendations of the SmartScreen filter.
SmartScreen is the spam filtering technology developed and operated by
Microsoft. SmartScreen is built around the technology of machine learning.
SmartScreen's filters are trained to recognize what is spam and what
isn't spam. In short, we filter incoming emails that look like spam. I am
not able to go into any specific details about what these filters
specifically entail, as this would render them useless.
Hotmail/Windows Live Mail limits the number of e-mail messages a
particular IP can send within a time period. Based on an IP's reputation
(built based on various data sources) it is allotted an allowed sending
limit per unit of time. When an IP (sender) exceeds its allowed limit, any
further SMTP commands from the IP will receive the SMTP error code 421
from Hotmail/Windows Live Mail and the connection terminated.
Please confirm that your emails comply with MSN Hotmail's technical
standards. This information can be found at:
http://postmaster.live.com/Guidelines.aspx
You may also be able to find additional information on common
delivery questions at the Hotmail Postmaster Site found at
http://postmaster.msn.com/.
Hotmail has created the Smart Network Data Services program. This is a
service that helps legitimate email senders work with their customers
and partners to reduce spam originating from their IP.
http://postmaster.msn.com/snds/. This program allows a sender to
monitor the 'health' of their IPs.
Monitor user complaints. Hotmail also has a sender complaint feedback
loop program Junk Email Reporting Program (JMRP). Enrollment in this,
free of charge, program will benefit you as a sender as it will keep your
e-mail lists updated and populated with interested MSN Hotmail
Customers. Participation in this program will remove those MSN Hotmail
Customers who do not want to receive e-mails from your company. If you are
interested in joining this program please visit
Http://support.msn.com/eform.aspx?productKey=edfsjmrpp&page=support_home_options_form_byemail&ct=eformts.
While using the SNDS tool, enrollment in the JMRP or having your IPs
registered with Sender ID will not allow emails from your mail servers to
bypass our filters, these are in place to help legitimate companies
deliver their emails to Hotmail Customers.
SenderScore Certified Mail Program. Many legitimate mailers and
marketers have qualified and joined this "white listing" program to improve
mail deliverability and decrease email from being filtered to the Junk
E-mail Folder. Sender Score is a third party program, administered by
Return Path. Sender Score (www.senderscorecertified.com) is the only White
Listing service to which we subscribe.
Below are some links which show the reputation results of your IP: x.x.x.x
Sender Score:
https://www.senderscore.org/lookup.php?lookup=x.x.x.x
Trusted Source:
http://www.trustedsource.org/TS?do=feedback&subdo=query&q=x.x.x.x
We would recommend working with both Sender Score and Trusted Source in order to build your reputation.
Hotmail has created a group of programs to help avoid future issues I would strongly
suggest enrolling-in or implementing these if you have not already.
1. Segment your mailing infrastructure by IP. Marketing e-mail,
transactional corporate, "forward to a friend" e-mail and signup e-mails
should be sent from different IP's. This will help to identify what types of
messages are being flagged by Hotmail customers.
2. Strengthen the sign up process. Confirm that you are using a
double-opt-in sign up process. This will not help in removing existing Hotmail
customers from your e-mail lists but it will confirm the authenticity
of those who sign-up on for your e-mail campaigns and newsletters.
3. If you have any feedback loops setup with other ISPs you should look
for trends to try and determine possible causes - a new data source?
New advertisement? Maybe folks signing up don't recognize the mail?
4. Clearly mark your e-mails so that Hotmail customers are able to
quickly and easily identify that they requested e-mails from your service.
5. Do some analysis on the data regarding complaints - look at Hotmail
customers who have never clicked, opened, responded or bounced in any
way. These poor performers could contain many bad addresses.
6. Clean up your lists. Remove those who do not want to receive the
emails. Make the unsubscribe process more visible.
7. Enroll in the Sender Score program. This is the only Whitelist which
Hotmail uses. It is owned and operated by Return Path. You can find
information about this program at http://www.senderscorecertified.com.
8. Please visit http://www.senderbase.org or http://openrbl.org to
verify that your IP is not being targeted by any 3rd party block lists.
The troubleshooting steps in this email are recommendations only,
Microsoft makes no guarantees that following these steps will guarantee
deliverability to MSN, Hotmail, or Live.com customers.
Windows Live Hotmail Domain Support
Is SPF the same thing as Sender ID? Which is better?
Is SPF the same thing as Sender ID? Which is better?
Executive summary
SPF and Sender ID are not the same. They differ in what they validate and what "layer" of the e-mail system they are concerned with. Sender ID is not the latest version of SPF – it is a new and independent experiment. The "spf2.0
" tag name is a historical accident. Neither is better because they address different problems. There is controversy because Sender ID is incompatible with existing specifications. Microsoft is aware of the problem and representatives of theirs have stated that they have no plans to fix it. There are practical work-arounds for SPF and Sender ID users.
Are SPF and Sender ID the same?
SPF and Sender ID are not the same. Both validate e-mail sender addresses, and both use similar methods to do so. Both publish policy records in DNS. Both use the same syntax for their policy records. So you have some excuse to be confused. They differ in what they validate and what "layer" of the e-mail system they are concerned with.
What is SPF?
SPF (defined in RFC 4408) validates the HELO domain and the MAIL FROM address given as part of the SMTP protocol (RFC 2821 – the "envelope" layer). The MAIL FROM address is usually displayed as "Return-Path
" if you select the "Show all headers" option in your e-mail client. Domain owners publish records via DNS that describe their policy for which machines are authorized to use their domain in the HELO and MAIL FROM addresses, which are part of the SMTP protocol.
What is Sender ID?
Sender ID (defined in RFC 4406) is a Microsoft protocol derived from SPF (hence the identical syntax), which validates one of the message's address header fields defined by RFC 2822. Which one it validates is selected according to an algorithm called PRA (Purported Responsible Address, RFC 4407). The algorithm aims to select the header field with the e-mail address "responsible" for sending the message.
Since it was derived from SPF, Sender ID can also validate the MAIL FROM. But it defines the new PRA identity to validate, and defines new sender policy record tags that specify whether a policy covers MAIL FROM (called MFROM by Sender ID), PRA, or both.
Is Sender ID "SPF 2.0"?
The tag for SPF records is "v=spf1
". It is defined by RFC 4408 to apply to the MAIL FROM and HELO identities only. The tag for Sender ID records can be "spf2.0/pra
", "spf2.0/mfrom
", or "spf2.0/mfrom,pra
", depending on which identities the policy applies to. Nevertheless, Sender ID is not the latest version of SPF — it is a new and independent protocol. The tag name is a historical accident and was assigned by the failed MARID IETF working group.
Which is better?
Neither is better because they address different problems. Comparing them is comparing apples and oranges. SPF can be compared to other SMTP layer protocol proposals like CSV/CSA. Sender ID can be compared to other RFC 2822 layer protocols like DomainKeys IM (DKIM). Nevertheless, the SPF technical community does have its own opinion on the merits of Sender ID.
Why is there controversy about SPF vs Sender ID?
The Sender ID specification contains a recommendation to use SPF's v=spf1
policies — which are originally defined to apply to MAIL FROM and HELO identities only — and apply them to the PRA identity as well. Specifically, it says to consider v=spf1
as equivalent to spf2.0/mfrom,pra
. This is technically wrong, as is explained in detail below. Sender ID implementors should correct this and treat v=spf1
records as equivalent to spf2.0/mfrom
. Unfortunately this mistake in the Sender ID specification was not corrected prior to its publication despite an appeal from the SPF project.
This creates a very bad situation in that Sender ID implementations that follow the recommendation in the Sender ID specification (RFC 4406, section 3.4) violate the SPF specification (RFC 4408). Since the Sender ID specification defers to the SPF specification for the definition of v=spf1
, and because SPF has been in existence (prior to the publication as an IETF RFC) a lot longer than Sender ID, the recommendation in the Sender ID specification should be ignored by implementors.
How will Sender ID implementations violating the SPF specification affect me?
If you have published an v=spf1
policy to protect the use of your domain in the MAIL FROM and HELO addresses, Sender ID implementations that apply your policy to PRA (per RFC 4406) will reject your mail if you use your domain in the "From
" (or generally PRA) header field while sending from (MAIL FROM) another system.
Informal surveys have shown that in roughly 80% of e-mail surveyed, MAIL FROM and PRA are the same. However about 20% may be wrongly rejected or flagged by Sender ID implementations. Microsoft is aware of the problem and representatives of theirs have stated that they anticipate the conflict to resolve itself as soon as domain owners are publishing all their v=spf1
policy records with the possible PRA interpretation in mind. Of course this is not going to happen as there are hundreds of thousands of v=spf1
records out there that were published long before Sender ID even existed.
What should I do if my SPF record is misinterpreted?
First, contact the recipient who wrongly rejected your message and explain the problem. Send them here to learn about the issue. If you are peers, you may even be able to convince them to get their Sender ID implementation fixed to respect the original meaning of v=spf1
records.
Domain Owners
Meanwhile, if necessary, as a domain owner you can prevent Sender ID implementations that violate the SPF specification from using your v=spf1
policy for PRA checking by publishing an explicit spf2.0/pra
policy. Unless you have researched and developed a PRA policy, you should publish an empty spf2.0/pra
record (i.e., "spf2.0/pra
"). There is no simple translation from MAIL FROM policy to PRA policy — they are different animals. Luckily, the Sender ID specification forbids implementations to fall back to a v=spf1
record for PRA checking if an (empty or not) spf2.0/pra
record exists.
Mail Users
As a user, you can work around the problem by making PRA and MAIL FROM the same. For instance, if you are trying to send mail with your domain in the "From
" header field, and Sender ID rejects it (because you are not sending from a system authorized by your v=spf1
policy), you can add a "Sender
" header field to your messages (to override the "From
" field with regard to PRA) with the domain you are sending from. Of course your mail client has to support this.
MTA Operators
Some people have experimented with working around Sender ID's incompatibility with SPF for mail that passes through their system by adding a "Sender
" (or other more obscure) header field with a copy of the MAIL FROM to force the PRA address to match. Use this approach with caution — it has not been fully investigated for unintended consequences.
Sender ID implementors
Ignore the recommendation in the Sender ID specification, section 3.4, to treat v=spf1
equivalently to spf2.0/mfrom,pra
. Instead, treat it as spf2.0/mfrom
. At the very least, make this configurable in your implementation and make the spf2.0/mfrom
interpretation the default.
Helpful Information forSender Information for Hotmail Delivery
https://support.msn.com/eform.aspx?productKey=edfsmsbl&ct=eformts&scrx=1
วันจันทร์ที่ 22 กุมภาพันธ์ พ.ศ. 2553
Email Marketing Knowledge Base
I've been blacklisted -ISP Listings
What to do if you get blacklisted or want to be whitelisting with a certain ISP.
If you have been blacklisted, the next step is to contact the ISP in question, and request to be removed from their blacklist (delisted). Each ISP has a process for applying, most starting with an online form. Here are links to some of the more popular ISP’s whitelisting/delisting applications
AOL
Go to webpage below, agree to terms, click accept and fill out form
http://postmaster.aol.com/whitelist/whitelist_guides.html
AT&T
Include your private IP address in the body of the email.
abuse_rbl@abuse-att.net
Adelphia
Contact Adelphia customer service desk at
800-683-1000 or 888-683-1000.
BellSouth
Include your private IP address in the body of the email.
http://www.postmaster.bellsouth.net/
Comcast
Include your private IP address in the body of the email.
blacklist_comcastnet@cable.comcast.com
Helpful Link
http://www.comcast.net/help/faq/index.jsp?faq=SecurityMail_Policy18628
CompuServe
Go to this webpage, agree to terms, click accept and fill out form
http://postmaster.aol.com/whitelist/whitelist_guides.html
Cox
Send us a copy of the bounced email notification to unblock.requests@cox.net
Excite
Send email to Excite asking to be removed from email blacklist
excite@mailca.custhelp.com
Gmail
A Helpful Website
http://www.google.com/mail/help/bulk_mail.html
Go here for messages being blocked or marked as spam
http://mail.google.com/support/bin/request.py?ctx=bulksend&nomods=1
Hotmail
Hotmail is very strict with spam complaints and they DO NOT bounce emails. They only filter to trash or junk mail. If they get only a few they will filter all email from your account. They will also filter if they detect you are sending to many non-existent accounts, since this is a characteristic of spammers.
If you use your own domain name as your FROM EMAIL ADDRESS, you can set up SPF records under your domain that will improve delivery to Hotmail. Hotmail uses senderID to accept mail and require that you set up spf records on the domain you use for your FROM email address. You will need to contact your host and ask them if they publish SPF records and are compatible with Microsoft's Sender ID initiative. Unfortunately, this is the only way to ensure delivery to Hotmail due to Hotmail's policies.
Once you have set up spf records, let Hotmail know by sending them an email at senderid@microsoft.com with your domain name in the body. We will then configure your Email System account accordingly.
If you are not sending from your own domain, our only recommendation is that you wait 48 hours or more between sends. Hotmail may remove your account from their filtering if they do not receive complaints within a certain span of time.
Useful articles:
http://emailuniverse.com/ezine-tips/?Ezine-Delivery-Into-MSN-and-Hotmail-Now-Requires-Sender-ID&id=1290
http://www.clickz.com/showPage.html?page=3497251
Juno
Getting onto whitelist:
http://www.unitedonline.net/postmaster/whitelisted.html
Email being blocked:
http://www.unitedonline.net/postmaster/blocked.html
Netzero
Get on whitelist
http://www.unitedonline.net/postmaster/whitelisted.html
Email being blocked:
http://www.unitedonline.net/postmaster/blocked.html
Roadrunner
Follow instructions for removal.
http://security.rr.com/mail_blocks.htm
SBCGlogal
Include your private IP address in the body of the email.
abuse_rbl@abuse-att.net
USA.NET
All blacklisting/IP block issues can be reported to postmaster@usa.net.
Additionally, you may want to consider registering for our feedback loop at
http://fbl.usa.net which exempts registered IP addresses from most spam
controls and allows contact if we see any delivery issues.
Verizon
http://www2.verizon.net/micro/whitelist/request_form.asp?id=isp (whitelist application)
Yahoo
https://mail.google.com/support/bin/answer.py?answer=81126
http://www.interspire.com/content/articles/6/1/Avoiding-the-Spam-Filters-and-Other-Email-Marketing-Tips
http://www.interspire.com/content/articles/64/1/How-to-Improve-Your-Email-Deliverability-Rates
http://help.yahoo.com/l/us/yahoo/mail/postmaster/basics/postmaster-15.html;_ylt=AmHLfHkAF1C9h9nisqQNbHAIJHdG
Or try
http://www.spambag.org - Commonly used blacklist used by Yahoo
*** If you have received an error message regarding 88.blacklist.zap, they are quick to help with delisting issues-- you should send an email to the email address below and include the IP address:
delist@bigfish.com
If you would like some helpful tips on not getting blacklisted again please visit the link below:
EarthLink
Please send an email with the complete header to openrelay@abuse.earthlink.net
Allow 12-24 hours, our server engineers will fix the issue once the email is received.
วันจันทร์ที่ 1 กุมภาพันธ์ พ.ศ. 2553
.htaccess
LoadModule rewrite_module modules/mod_rewrite.so
จากนั้นกำหนดที่ "
AllowOverride All
สร้างไฟล์ .htaccess ไว้ที่ DocumentRoot ของแต่ละ VirtualHost
ตัวอย่างการ Force ssl
แบบแรกบังคับทั้งหมด
RewriteEngine Onแบบสองบังคับเฉพาะที่เข้าไปที่ /somefolder
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://www.example.com/$1 [R,L]
RewriteEngine On
RewriteCond %{SERVER_PORT} 80
RewriteCond %{REQUEST_URI} somefolder
RewriteRule ^(.*)$ https://www.domain.com/somefolder/$1 [R,L]