The trusted-forwarder.org domain provides a global whitelist (the T-FWL) for users of the SPF system. It provides early adopters of SPF a way of allowing legitimate email that is sent through known, trusted email forwarders from being blocked by SPF checks simply because the forwarders do not use some sort of envelope-from rewriting system.
The trusted-forwarder whitelist is NOT part of the SPF specification, its use is completely optional and up to individual mail admins who receive email. Many mail admins choose not to use the T-FWL and some SPF implementations don't even support its use. The T-FWL is designed to help mail admins who receive email, not the email forwarders (although they are helped also).
As explained below, mail forwarders being listed on the T-FWL is not a good substitute for doing envelope-from rewriting. The Sender Rewrite Scheme (SRS) is one such method of doing the envelope-from rewriting, but there are others.
For more information about SPF, see: www.openspf.org
For more information about SRS, see:
libsrs2.org or
www.openspf.org/srs
The T-FWL lists both domain names and IP addresses of email forwarders (e.g. sneakemail.com), and other systems (e.g. ebay.com), that send email using domain names that they don't own. As such, T-FWL is both a DNSWL and a RHSWL.
The requirements to be on the T-FWL are:
The mail server MUST be the source of one of two kinds of email:
The mail server can be a mail forwarder, such as sneakemail.com, mail.spamcop.net, or pobox.com. That is, anyone can send email to them, and the mail server will forward it on, in a controlled fashion, to the mailbox of someone who has requested the forwarding.
The mail server allows individuals to send email using the mail server to others in a controlled fashion. For example, ebay.com allows members to send email to other members and the emails have envelope-froms that match the members email accounts. Ebay can prevent abuse because any member who starts sending spam can be traced back to the member and terminated. Ebay not only can prevent abuse, but it also does a good job of dealing with abusive members.
The mail server MUST not have significant spam problems.
Being listed on any of the major DNSBLs or being involved with spams contained in any of the major spam sightings/example databases will likely prevent the mail server from being listed. A small amount of spam may be acceptable if the overall percentage is low enough or if it appears that the spam complaints are bogus. I reserve the right to make the final decision on these issues.
Mail servers that send both forwarded email and email from poorly controlled sources are unlikely to be listed, even if the forwarded email is well controlled.
The mail server MUST be located at a well defined location on the Internet. A mail forwarder that uses a dynamic IP pool will not qualify for having its IP addresses listed (and it will probably not be listed via its domain name either.) A domain name that uses many different mail servers, especially third party mail servers, will not qualify to have its domain name listed in the T-FWL.
I must know about the domain and/or IP address. :->
It is also highly recommended that the forwarder perform SPF checks on incoming email on behalf of their clients. After all, the T-FWL is used by people who check SPF records and the T-FWL is just a way of making an exception for the forwarders.
Greeting-card sites and news sites that allow anyone to send email to anyone else claiming to be anyone in the world do not qualify to be on the T-FWL. While these sites are not that frequently abused, they lack the controls needed to prevent and track abuse.
I have considered creating a separate whitelist for such sites, but so far, there has been little interest from mail admins for such a whitelist. (Remember, the purpose of the T-FWL is to make life better for mail admins who receive email, not sites that send email.)
Many SPF implementations have a "local policy" built in that automatically checks the T-FWL when email is received and usually it is enable it by default. You will need to review the documentation for the particular MTA or SPF implementation that you are using for details.
Mail admins that receive email may wish to explicitly use the T-FWL rather than relying on a default configuration. If so, they should create a "local policy" mechanism of "include:spf.trusted-forwarder.org".
Authors of SPF implementations should use the same mechanism. It is not safe to rely on the details of how the SPF record at spf.trusted-forwarder.org is written because it will likely change in the future.
Domain owners that send email do not need to do anything with the T-FWL since it is all handled by the receiving MTA.
You will need to send me the following information:
The domain names that should be listed. (In cases where a mail server sends email for many domains, it is likely to be better to just request the appropriate IP addresses.)
The IP addresses that should be listed. (In cases where a domain has such a high volume of email that it needs to use many MTAs to send email from, it is likely to be better to just request the appropriate domain names.)
Some sort of evidence that the mail servers actually forwards email or send email using other people's domain names.
Some sort of evidence that the mail server can't just use their own domain name in the envelope-from. Sending the forwarder an email requesting them to do so and a refusal from them to comply will probably qualify right now, but might not in the future.
Something that will convince me that this mail server can be trusted.
Nope! Not at all!
The T-FWL is to help mail admins who receive email. If you think a domain or mail server should be listed, let me know.
Yes!
The complete T-FWL is available for anyone to use for any purpose. Feel free to uses it as a starting point for a local replacement, or to create a better-run-trusted-forwarder.org or anything else that you would like to do.
Copies can be obtained via a DNS zone transfer, such as using the command:
dig @dns.trusted-forwarder.org -t AXFR trusted-forwarder.org
Note that the IP address of the primary name server for the T-FWL has changed in the past, and will likely change in the future. If, instead of using the above command, you set up a stealth secondary with a hard coded IP address, then you need to verify that the IP address has not changed.
You can also obtain it via rsync with the command:
rsync rsync://trusted-forwarder.org/ftp/master.trusted-forwarder.org .
Or, of you want to, you can fetch it via the web:
http://trusted-forwarder.org/master.trusted-forwarder.org
No.
The T-FWL is designed for early SPF adopters. It is not in the SPF specification for many good reasons. There should never be a single entity that can decide if email should get through or not.
Fortunately, the T-FWL is designed so that it will become irrelevant once SPF usage becomes widespread, and if SPF doesn't become widespread, then both SPF and the T-FWL will be irrelevant.
No responsible mail forwarder will want to depend on being listed in the T-FWL in order to have their email safely delivered. They will not want to have to make sure new MTA IP addresses get listed before they are put into service. They will not want to depend on anyone but themselves. This is especially true since not all mail admins who receive email will check the T-FWL.
Similarly, no responsible mail admin will want to depend on the T-FWL to make sure they accept valid email. Many will choose to either not use the T-FWL or to pressure the email forwarders to not spoof other people's domain names.
It is only until SPF reaches a critical mass that many mail admins will feel the need to use the T-FWL. If an email gets blocked due to an SPF check, mail forwarders will likely just say "tough, don't use SPF." Once SPF becomes widely used, however, mail forwarders will face the choice of either fixing their system so that they do not use other people's domains without authorization or having a lot of the email blocked.
There is a important corollary here: There is little to no advantage for spammers to create a denial-of-service attack on the T-FWL. Not only will such an attack do nothing to help them get their spam through, but since the T-FWL is designed to go away, an attack would accomplish nothing.
The T-FWL will likely be around for at least another couple of years, and likely much longer. The exact length of time will depend on how quickly people adopt SPF.
Completed Oct 2003:
trusted-forwarder created.
Completed Feb 2005:
I will no longer actively look for mail forwarders and
silently add them.
No sooner than the winter of 2005-2006:
I will no longer accept new mail forwarders for inclusion into
the T-FWL. Only existing mail forwarders that are already in
the T-FWL will be maintained. If a mail forwarder isn't
significant enough to be known about by this time, they are
unlikely to be worth listing.
No sooner than 3 months after the completion of previous item:
I will start recommending that SPF implementations make
T-FWL usage not enabled by default. Mail admins should
still be able to use it by creating a local policy mechanism
and/or enabling an option.
No sooner than 3 months after the completion of previous item:
I will not add new MTAs to the T-FWL, I will only remove IP
address and domains that are longer need whitelisting.
No sooner than 3 months after the completion of previous item:
I will empty the T-FWL so that mail servers will no longer be
whitelisted. I will do this in a fail-safe way so that older
installations will continue to function.
No sooner than 2 years after the completion of previous item:
I will keep the trusted-forwarder.org domain around so that no
one else can claim it and do destructive things with it.