Reference: Notices-SPF

16 May 2008

We have recently seen a large increase in Mail Server Rejection notices based upon inappropriate use of Email addresses by SPAM operations and, in fact, generally increasing SPAM activity based upon Sender Address Forgery.

Recent Symptoms have been the receipt of a relatively large number of Email messages in your Inbox with a subject like "Mail delivery failed: returning message to sender", "failed delivery", "Undelivered mail", etc.

What causes all the Mail Server Rejections?

Some other Internet User (the SPAM operation) has initiated an Email message to a target email address utilizing your Email address as the Sender. Yes, this is illegal in Washington State (as well as many other States and Countries), but...the fact remains that they can technically do this utilizing their own Mail Server from anywhere in the world. The spammer may have harvested your email from your website, received it from addresses collected via Virus infections, or even purchased it from vendors providing lists of Email addresses. Thus, the actual "source" for where they got your email address is essentially unknown (although many of the afflicted addresses are published on public pages on the web).

When the email they initiated reaches its intended recipient, the recipient's Mail Server will follow SMTP protocols and attempt to deliver it. However, should the email address be unable to be delivered (for whatever reason), the recipient's mail server will inform the sender (that's you, because of the email address forgery) that the message cannot be delivered and, usually, why it cannot be delivered. It is these Mail Server Rejection Messages that are crowding everyone's Inbox recently.

This particular problem is described by the phrase Sender Address Forgery. It is that the SPAM activity is utilizing an Email address that does not belong to them (hence, Forgery).

Sender Policy Framework

In an effort to address this problem, an Internet Architecture called Sender Policy Framework (SPF) has been proposed and subsequently adopted (in April 2006 as RFC 4408) for implementation. The project specifies a mechanism where individual Domain Owners can identify which systems on the Internet are capable of initiating Email for the Domain.

Receiving Mail Servers with SPF support active can check back with the SPF enabled sending Domains to determine if incoming mail was sent from an approved source. If it was not, the incoming mail can be rejected, should the Receiving Mail Server be configured to do so. In short, the owning Domain can indicate which specific messages are legitimately from the domain and which are not.

Implementation at RidgeStar

For some RidgeStar clients, all valid email from their Domain originates from the RidgeStar mail servers. Thus, adding SPF entries to the RidgeStar domains can simply declare that Email from other sources should not be trusted.

As of the date of this Notice, all RidgeStar based Client Domains that we provide Outgoing SMTP Mail Service for have been put into SPF "SoftFail" mode for email that originates from a non-RidgeStar source, which means Email from non-RidgeStar mail servers will be marked as likely invalid, but should be "accepted and marked" as we're in transition to a full Fail mode.

We will be contacting each SiteManager directly to confirm how they use Email based upon their domain (SPF=Fail will be implemented domain by domain). The objective being to establish the SPF characteristics and migrate their domain to a full Fail mode. We believe that this will be a great aid in reducing (over time) the volume of Sender Address Forgery that is occurring and reduce SPAM based email.

For more information, do look over the OpenSPF site, it explains in great detail the background and implementation associated with the Sender Policy Framework architecture.

SiteManager

Things to ask yourself about all your defined Email addresses (see Administrator: RidgeStar-Email) to determine if your Domain can go to SPF=Fail status:

1. Does all Email using my domain go out through the RidgeStar Mail Servers or originate from the RidgeStar Site(s)?
   Yes: You are ready to go SPF=Fail
   No: Carefully identify which Email users do not send outgoing mail through the RidgeStar Mail Servers and why.
2. Do any of my defined Email addresses send their outgoing email through ANY non-RidgeStar Mail Server?
   No: Good, you're ok to go SPF=Fail.
   Yes: All RidgeStar POP3 type accounts should be using the RidgeStar outgoing mail server. RidgeStar can add the outgoing mail server they're using as a valid server, but contact RidgeStar for the CONs to that (we require that any other outgoing Server that may be defined participate in SPF architecture).
3. Do any of my Email addresses (particularly Forwarders) set their Reply-To address to a RidgeStar domain based address, but use a non-RIdgeStar mail service to send and receive email?
   No: You're ok to go SPF=Fail.
   Yes: They should change to use the Reply-To email address to the local domain (non-RidgeStar) email address or convert the email address to a RidgeStar based POP3 account or Alias.

Please keep in mind that to implement SPF properly, we are all constraining a bit the flexibility provided by general SMTP protocols and operational mechanisms. This is the cost to more carefully defining who can use the Domain for Email origination and reducing unwanted Sender Address Forgery!