On Fri, 9 Feb 2007, David MacQuigg wrote:
At 05:23 PM 2/9/2007 +0100, Alex wrote:
Anyway, we seem to drift further and further away from the true topic
of this list: fighting email forgery using SPF. I think we should not
continue to define semantics of spam, uce, ube, "une" and such here.
I'll agree with that, but I'm would like to hear more discussion on the
proposal that we should have a special category for SCE (or whatever we want
to call it). Discussion of reputation systems is a bit outside the scope of
SPF, but I believe the topic is relevant to SPF, because the true value of
SPF will only be realized when it is used in conjunction with a reputation
system, and the needs of reputation systems should influence further
development of SPF.
I agree that reputation should be take into account when talking
about and how to extend SPF but I'd disagree about "true value"
though obviously true value is in the eye of the beholder...
My initial opinion is that opening up a special category for SCE will blur
the line between spam and ham, and that *any* legitimate sender can avoid
getting near that line by simply sending a clearly-worded confirmation email
before adding an address to their list. That will take care of the broker
who sincerely understood that I had requested more "information".
Reputation data request about certain email is basically request about
some data where you do not recognize the sender. So instead of
talking about "SCE" as you name and some special arrangements for
known ones (which in the end will depend on reputation vendor)
what you should have is that if you know that email came from
known entity that you requested to receive emails from, then
this email should be whitelisted based on user preferences.
Though this is more of the topic for ASRG (which is due to current
management is largely not productive and as a result sees very
little discussion on reputation schemes or ideas for anti-spam)
what you should really have is mechanism that user could confirm
his request to be subscribed to email vendor which then allows for
easy whitelisting on the user side. One option is using encrypted
confirmation response. Lets assume that user 'david(_at_)example(_dot_)com'
has private key KEY for use with symmetric key encryption system.
The user receives a request for confirmation from 'ESP(_at_)example(_dot_)net'
and what he does is create encrypted token for example:
TOKEN=sha1(KEY,'david(_at_)example(_dot_)com','ESP(_at_)example(_dot_)com')
and replies to the provider with new email address for subscription
from new provider-specific address
TOKEN#david(_at_)example(_dot_)com
Now if ESP(_at_)example(_dot_)com sends new email to
TOKEN#david(_at_)example(_dot_)com
then mail system could at the SMTP session time verify that request
came from confirmed ESP by doing same SHA1 calculation using given
MAIL FROM and RCPT TO addresses.
This is not the only way to do something like this obviously but
if you do it as above you can easily whitelist known good senders
without having to maintain large list of those senders and so after
you verified using SPF or that true sender is really ESP(_at_)example(_dot_)net
you avoid having the email subjected to further reputation checks.
There is still the practical problem that Stuart detailed at the start of
this thread. How can an automated reputation system deal with legitimate
senders of SCE (e.g. amazon.com)? My initial thoughts are that it can't be
automated, at least not for senders just getting started. Established
senders of SCE should have no difficulty *maintaining* a good reputation,
because any lowering of that reputation should be based on human feedback,
and there will be plenty.
New senders of SCE will probably need the help of an accreditation service,
or perhaps a "voucher" from their ESP or trade association. Or they can
simple relay their mail through their ESP's server, and rely on that ESP's
reputation to ensure delivery. Any of these options can be implemented
in a reputation system without establishing a separate category or
procedures for SCE.
You're mixing some concepts & systems above. Reputation system is one
concept but what you're really talking about above is comprehensive
anti-spam system. Such comprehensive system would use results from
both accreditation/whitelisting and reputation checks.
The accreditation service is treated the same as any rating service,
and will lose its credibility if it is not careful.
Yes, reputation rating of accreditation providers is concept that
has been mentioned. I suspect that is way in the future though.
Vouchers simply say "treat this email as if it came from us". The
vouching ID can then be held responsible. Relaying requires the
least change in status quo. I am not aware of any deliver-ability
problems in mail I have sent via my two relays - yahoo.com and
controlledmail.com. (I have not tried any mass mailings, however).
I suspect that vouchers would still have to be reputation database
maintained in different way then normal reputation database of
identified senders even though as you point out when you
"treat this email as if it came from us" you can maintain together.
My view of this is that if you base reputation not on just one
name but on (name, identity_type) pair where 'identity_type'
is "MAIL FROM" or "EHLO", etc - then the reputation of the
accreditor is in fact type of identity with name being replaced
with "accreditation provider name", i.e. you'd have pair
("accreditor.example", "ACR") in your reputation database.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735