Mina-san!
Excellent news have I! Well, in reality, I've known for a long time and
have been waiting for the opportunity to share this with you, but first
a little background...
On May 11, 2004 the Government of Canada announced the creation of a
joint government / private sector task force to combat spam. This task
force has facilitated the collaboration between the Government of
Canada, industry, and consumer groups. The first task was to supply the
Canadian Government with advice on how to proceed. This report was
ratified at the end of 2004 and submitted to the Honourable David L.
Emerson, Minister of Industry.
Whilst working for Delta Cable Communications I was fortunate enough to
be invited to participate in this task force due to my involvement with
SPF. When I joined work was well underway, however to my delight the
members of the working group had already come to the conclusion that
publishing SPF records was already a recommendation! Not only was it on
their list, but it was their #1 recommendation! Good news indeed!
All was not right however, as the wording was poor and lumped SPF in
with SenderID. I lobbied for a significant change in the wording, in
fact, I requested that all mention of SenderID (other than in stating
its existence along with Domain Keys, etc..) be removed.
This is not to say that a fuss wasn't made about my request. John
Weigelt, Microsoft Canada's Chief Security Advisor took it upon himself
to write the list in protest. John attempted to argue that SenderID had
seen widespread adoption.
Of course thats an outright lie (SenderID seeing widespread adoption),
but I was prepared for this, and it was not hard to refute, and thus
more or less, the changes stayed. I'm attempting to verify that I may
share some posts made to the mailing list we used as a communicative
medium (regular conference calls were also held and the combination of
the two proved quite powerful, although I must admit, its just not the
same as IRC :-)).
The recommendations set force by our Task Force were discussed at great
length, and much time and effort was put into both the recommendations
themselves, the wording of them, and the wording of their accompanying
explanations to ensure that they were not only plausible but also
considerate, and likely to be effective and adopted. With this in mind
I am sharing this with you all because I think its important that people
know whats going on behind the scenes. I'll be the first to admit that
SPF *IS* a flawed technology. I'll also happily be the first to admit
that there is a solution (*cough* SES http://ses.codeshare.ca), and
there is still time and merit in furthering the SPF CLASSIC effort.
I see SPF simply as a means of publishing in DNS, a way to describe ones
network for the intended employment by third parties participating in
electronic mail exchange over the Internet to gauge the validity of an
inbound message. Nothing more nothing less. SPF's true value is moot
until we've got everyone publishing. With that in mind I leave you with
a link to the finalized report submitted to my Government, and the list
of recommendations:
As taken from APPENDIX B: RECOMMENDED BEST PRACTICES FOR INTERNET
SERVICE PROVIDERS AND OTHER NETWORK OPERATOR, from the May 2005 Report
of the (Canadian) Task Force on Spam:
Reference URL:
http://e-com.ic.gc.ca/epic/internet/inecic-ceac.nsf/en/gv00330e.html
1. All Canadian registrants and hosts of domain names should publish
Sender Policy Framework (SPF) information in their respective domain
name server zone files as soon as possible.
2. ISPs and other network operators should limit, by default, the use of
port 25 by end-users. If necessary, the ability to send or receive mail
over port 25 should be restricted to hosts on the provider's network.
Use of port 25 by end-users should be permitted on an as-needed basis,
or as set out in the provider's end-user agreement / terms of service.
3. ISPs and other network operators should block email file attachments
with specific extensions known to carry infections, or should filter
email file attachments based on content properties.
4. ISPs and other network operators should actively monitor the volume
of inbound and outbound email traffic to determine unusual network
activity and the source of such activity, and should respond
appropriately.
5. ISPs and other network operators should establish and consistently
maintain effective and timely processes to allow compromised network
elements to be managed and eliminated as sources of spam.
6. ISPs and other network operators should establish appropriate
intercompany processes for reacting to other network operators' incident
reports.
7. ISPs, other network operators and enterprise email providers should
communicate their security policies and procedures to their subscribers.
8. ISPs and other network operators should implement email validation on
all their Simple Mail Transfer Protocol (SMTP) servers (inbound,
outbound and relay).
9. Non-delivery notices (NDNs) should only be sent for legitimate
emails.
10. ISPs and other network operators should ensure that all domain
names, Domain Name System (DNS) records and applicable Internet protocol
(IP) address registration records (e.g. WHOIS, Shared WHOIS Project
[SWIP] or referral WHOIS [RWHOIS]) are responsibly maintained with
correct, complete and current information. This information should
include points of contact for roles responsible for resolving abuse
issues including, but not limited to, postal address, phone number and
email address.
11. ISPs and other network operators should ensure that all their
publicly routable and Internet-visible IP addresses have appropriate and
up-to-date forward and reverse DNS records and WHOIS and SWIP entries.
All local area network (LAN) operators should be compliant with Request
for Comments (RFCs) 1918 — "Address Allocation for Private Internets."
In particular, LANs should not use IP space globally registered to
someone else, or IP space not registered to anyone, as private IP space.
12. ISPs and other network operators should prohibit the sending of
email that contains deceptive or forged headers. Header-tracing
information should be correct and compliant with relevant RFCs,
including RFC 822 and RFC 2822, and reference domains and IP addresses
should have up-to-date, accurate registration information.
Full Report entitled:
"Stopping Spam Creating a Stronger, Safer Internet":
In HTML format: http://tinyurl.com/bbvc7
In PDF format: http://tinyurl.com/7r7s3
Woot!!
Cheers,
James
--
James Couzens,
Programmer
http://libspf.org -- ANSI C Sender Policy Framework library
http://libsrs.org -- ANSI C Sender Rewriting Scheme library
-----------------------------------------------------------------
PGP: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x7A7C7DCF
"This is not quite as crazy as it sounds, since people knew how
to write small, efficient programs in those days, a skill that
has subsequently been lost." -- Andrew S. Tanenbaum
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper! http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
signature.asc
Description: This is a digitally signed message part