I'm reluctant to join the fray as I find myself feeling caught in the
middle. Long time lurker, first time poster.
I speak for myself but work for a well known website which generates a
fair amount of outbound mail mainly from a web GUI interface which
customers interact with. Phishing is an issue for my employer and we
are clearly interested in solutions which work. We have changed our
mode of operation so that we could publish SPF1 records (by not
sending emails as if it was the user sending them). We also recognized
that other solutions such as CallerID and DomainKeys were on the
horizon.
The merging of CallerID and SPF into SenderID presented an opportunity
to provide a generally accepted solution to reduce forgeries for both
RFC2821 and RFC2822 headers. The issue of licenses does not directly
impact us with the most recent changes made by Microsoft as we would
simply be an end-user.
I recognize that there is significant controversy over the licensing
issue with many posters to this list indicating that they will not
implement SenderID given the current situation. Fragmented
implementation of standards (specified or de facto) by recipient MTAs
(I'm setting aside the issue of MUAs as it would take a longer time
frame for implementation in any event) is perhaps worse than no
implementation at all. The risk of lost communications or
troubleshooting problems would at best be difficult. Differing and
competing implementations, whether within a standards framework or
outside of it, is likely to have a potentially large negative impact
on a core service provided over the Internet.
Given that last call is almost over and considering the lack of
consensus with regard to SenderID, I would prefer to see the Working
Group not put forward SenderID but I would not like to see it killed.
If core and unified SPF could be moved forward or simply SPF classic,
that would at least be a step in the right direction. There is
potential in SenderID that should not be discarded lightly. Given more
time and less "heat" it may be possible to resolve the current issues
given some flexibility by all concerned.
To illustrate why consensus is important to deployment I decided to do
a little checking after reading the post from J . Trevor Hughes
stating how strongly ESPC and it's members support SenderID. I
decided to check the extent to which members of the Email Service
Provider Coalition have published either SPF1, SPF2.0/PRA or both. The
results are somewhat interesting and bear on the issue of deployment.
This is clearly a group of companies which should have a strong
interest in authenticated email solutions (As Mr. Hughes pointed out
in his email). If there are issues with achieving deployment (of
anything) by a group that should have the strongest motivation, what
happens when various large recipient (mail service providers) impose
inconsistent requirements on sending MTAs? My concern is that the
larger universe of organizations and companies will simply ignore any
standards and go with whatever meets their immediate need.
The results are as follows:
52 companies listed
27 have no TXT record in DNS (more than half)
17 have SPF1 only
3 have SPF2.0/PRA only
4 have both SPF1 and SPF2.0/PRA
The detailed list as follows:
NO Adknowledge, Inc.
SPF1 aQuantive
SPF1,SPF2.0/PRA Constant Contact (Formerly Roving Software)
NO Digital Impact
SPF1 DoubleClick
NO Experian
NO Got Marketing
SPF1 ProspectivDirect
SPF2.0/PRA SKYLIST
NO 24/7 Real Media
NO @Once
NO Acxiom
SPF1 Advertising.com
NO AFG Media
SPF1 Bigfoot Interactive
SPF1 BlueHornet Networks, Inc.
NO BlueStreak
SPF1 Britemoon
SPF1,SPF2.0/PRA CheetahMail
NO Datran Media
NO Digital Connexxions
NO eDialog
NO EmailLabs
SPF1 ExactTarget
NO Exmplar, Inc.
SPF1 IMN
SPF1 Inter(_at_)ctivate, Inc.
SPF1 Internet Marketing Center
NO The Lift Network
NO Mediaplex
SPF1 NetCreations, inc.
NO Performics
SPF1,SPF2.0/PRA Pexicom, Inc.
SPF1,SPF2.0/PRA Port25 Solutions, Inc.
NO Postfuture
SPF1 Quris
NO RightNow Technologies
SPF1 Responsys
NO Return Path
NO Savicom
SPF1 Silverpop
SPF2.0/PRA SmartSource
NO SourceLink
NO StrongMail Systems
YES SubscriberMail, LLC
SPF2.0/PRA TargitInteractive
SPF1 Topica
NO Traffix, Inc.
NO TranSend, Inc.
NO ValueClick
SPF1 VerticalResponse
NO Yesmail
Michael Hammer dotzero(_at_)gmail(_dot_)com