Dan/e-card sites could generate a key and email address and request you
send
the first email to register. The ecard could use SPF and whatever else to
verify that the email is not forged. Then it would send an email with a
confirm link or whatever they would normally do.
Wouldn't stop people from signing you up on the web for the signup mail.
Our web site describes best practices for web generated mail. AFAICT, Dan
has done all we asked and even donated code to make it easier for others
to
do the same. What he's gotten in return is a large ration of grief.
Personally I'm very dissapointed in the community's reaction to Dan trying
to do the right thing.
If we need a best practice on validation of web entered e-mail addresses,
let's write it up and get some consensus. Let's quit berating Dan for not
doing stuff we haven't even bothered to write down.
Scott K
Hello.
Thanks Scott for defending me, that's appreciated. No problems, sometimes we
all slide in some eagerness too quickly.
Forgiveness is also a best practice to be learnt and applied ;-)
No problems Guy, you were not seen as offending me at all yourself. I have
understood your constructive suggestion about displaying only the cookie on
the web page, and requesting the user to send the e-mail first. It is an
option which would avoid a service to be used as a spam box.
Nevertheless, I think that the question of how we should register or how we
should do to avoid having a mail sent to anyone we want is to my opinion
sliding outside of the first aim about the sample code's security.
The sample code is only handling bounces, it is not how you register people,
how you let them send an e-card. This is something on top, that the ecard
provider have to solve. This is why I believe we should leave others get
involved on that question, and I don't think this is an SPF community issue.
The reason is that just any service can be used as a spam box this way, even
the SPF mailing list when we request a subscription. In that thought, these
ecard services are not more dangerous than all mailing lists as for their
potential spam abuse. I think we are too keen on security issue where there
is no need to see such a thing, unless there are real abuses, and we are
going too far in this concern IMHO.
Anyhow, here are my conclusions about the sample code.
1. The code does what it is intended for, and does it well: it allows
anybody to produce a service which sends an SPF compatible e-mail on behalf
of someone else, by forcing the sender's email address and keeping the
Return-Path address of the sending server, like suggested on the SPF
technical page, and helps to do so by providing a bouncing system which
takes care to handle these bounces and report in a _very_ secure way to the
sender that its destination address failed if it was the case (because
combined with the unique random ecard ID checked against the database). This
code cannot be abused by spammers.
2. The security of this code is not involved, but it is transferred to the
ecard/other service generator which must take care of the verification of
the real sender's address. As for the forging capability of hties system,
and thus the spam abuse potential, he can do this with Guy's suggestion of a
cookie displayed on the page, which the user should copy and paste in a new
e-mail he sends to a predefined e-mail address. This would probably be the
highest security system. A second level would be a captcha with each sent
e-cards would already be something quite secure, because automated systems
would not be able to use the service at all, even if one person could still
harm anyone else by hand. The third level is that there is no captcha, but
there are other limitations to the service which prevents spammers to use
the service as they would like. These limitations are notably to check the
sender's IP address against an online IP spam blacklist. I believe that the
third level is already enough, and we could further discuss about this. This
third level is better or equal to the level of security everyone uses on the
web, like for mailing lists, 'send this page to a friend', and so forth. I
don't believe that it is something which really causes spam dangers on the
internet, due to the described limitations of the service.
Thanks to all again. I think we have been able to construct something which
I hope is the right thing.
Regards,
Daniel
-------------------------------------------
-----------------------------------------------------------------------
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
Powered by Listbox: http://www.listbox.com