There is another solution - multiple secrets - I don't know the details of
SES enough to be declarative, but having a disposable secret would solve the
problem. This is also a developing problem with Certificates and the
assumption that the one to one relationship is between the individual and
the certificate. I think the one to one relationship will turn out to be the
individual and the channel, the implication being that people will not have
a certificate, but rather a certificate authority. This is already the case
with e-mail addresses for many people, including myself.
or not - Ed
-----Original Message-----
From: Seth Goodman [mailto:sethg(_at_)GoodmanAssociates(_dot_)com]
Sent: Thursday, April 22, 2004 5:39 AM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: RE: [spf-discuss] Sender forwarding
From: spf(_at_)metro(_dot_)cx
Sent: Thursday, April 22, 2004 3:31 AM
On Wed, Apr 21, 2004 at 06:33:26PM -0500, Seth Goodman wrote:
addresses. Sorry for the SES evangelism, but I will point out
that SES can
handle this case gracefully. The user would have to enter
their hash secret
(home domain password) along with their email address. The
application at
the hospital would create an SES signed return path and
the hospital MSA
would do a CBV to the user's home domain MX to verify
that the user has
And then the hospital (or any other webservice provider that does
this) has a nice sellable list of SES secrets they can market to
the spammers community??
If a hospital was willing to sell my private information, my
SES secret
would be the least of my worries.
Your point is well taken when it comes to greeting card
sites, etc. I would
never give out my password (or hash secret) to a site like
that, despite any
assurances that they give. The SES verification solution
only works for
sites that you trust not to harvest/sell your information.
Untrusted sites that you wish to send mail from are a problem
no matter how
you deal with them. If you allow/encourage them to accept
and trust any
return-path address a user claims, tell them to pretend
they're forwarding
and construct an appropriate SRS address, you've just created a
"bullet-proof" spam portal. Their outgoing mail appears like
a forward that
went through the normal SPF checks before rewriting. This
gives it an air
of legitimacy that is inappropriate.
Another possibility is a trustedforwarder.org or
bondedsender.org type of
solution. If SMTP AUTH were available, I suppose you could
have the third
party site submit the mail to your provider via that
mechanism, but there
you are entering your account name and password again at
their site. An old
school method would be to verify the address by sending a confirmation
message that the user would have to answer before trusting
the address. The
user would respond through their mail client, if on their own
computer, or
through a webmail interface in a new browser window that the
user manually
opened on a foreign computer. This is secure on your own
machine but less
so on someone else's. What do you suggest?
--
Seth Goodman
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/spf-draft-200403.txt
Wiki:
http://spfwiki.infinitepenguins.net/pmwiki.php/SenderPermittedFrom/
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