On 5/1/14 2:54 PM, John Levine wrote:
author's site. That shouldn't require the mailing list to communicate
with the author's site, but it might require the author's site to get
something from the mailing list's site.
That seems overcomplicated. Just make the expiration time fairly
short, since it's a rare mailing list that takes more than a day to do
its thing.
Perhaps it's time for a more concrete proposal to be written down.
It occurred to me that there's a very simple way to do this:
http://datatracker.ietf.org/doc/draft-levine-may-forward/
On 5/1/14 2:54 PM, John Levine wrote:
author's site. That shouldn't require the mailing list to communicate
with the author's site, but it might require the author's site to get
something from the mailing list's site.
That seems overcomplicated. Just make the expiration time fairly
short, since it's a rare mailing list that takes more than a day to do
its thing.
Perhaps it's time for a more concrete proposal to be written down.
It occurred to me that there's a very simple way to do this:
http://datatracker.ietf.org/doc/draft-levine-may-forward/
I don't see any replay protection in here at all. Nothing that says to
keep the signature expiration relatively short, and nothing which a
mailing list recipient could not subsequently use to send spam. The
first issue just needs a mention. It's the second issue that needs to be
addressed IMO:
As an originating site, I do not want to give permission to forward to
just anyone. I want to indicate that I was sending to someone in
particular, e.g., list@a.example, and *list@a.example* has permission to
forward. (An originating site should be fine with their being a
subsequent re-forwarding, say list@a.example sending to list(_at_)b(_dot_)com which
forwards, but I think they'd expect list@a.example to have given
permission to list(_at_)b(_dot_)com to re-forward, and the eventual recipient will
be able to see that chain.)
That's why I suggest that the originating site is going to want to talk
to the mailing list site: "This message was sent from user@mydomain to
list@a.example. You had better see my signature *and* received it from
a.example." Your proposal doesn't do that.
Maybe people who are now setting p=reject don't care. Maybe all they
care about is a short-lived signature and permission to re-forward. But
I don't think that's likely to be true. I think they care about the
replay problem. Otherwise, it's inviting spammers to subscribe to
(especially well-used) mailing lists so that they can get and endless
supply of replayable signatures.
I wouldn't bother with what you've proposed.
pr
--
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478
_______________________________________________
ietf-822 mailing list
ietf-822(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-822