On Wed, Mar 17, 2004 at 02:29:41PM -0800, Hallam-Baker, Phillip wrote:
following up the great success of my accreditation non-proposal that nobody
wants to make a work item, here is a second.
Having read both there might be a reason for that...
Again the relevance is that the existence of the concept affects the spec
that MARID may produce. In this case however the point is to reduce the
scope of the spec by eliminating a particularly problematic set of corner
cases.
Detailed discussion should take place on ASRG.
One of the biggest headaches with any SPF/RMX like proposal is how to deal
with a forwarding relationship. I.E
Mail is send to
alice(_at_)alumni(_dot_)ardvark(_dot_)com
It is then forwarded to alice(_at_)homeisp(_dot_)net
The change of the email address in mid stream is problematic because it
means that homeisp.net will be receiving the mail from the
alumni.ardvark.com forwarder and not from the place it is expected to come
from.
Provided alumni.ardvark.com has implemented something like SRS
along with SPF/RMX than this issue is completed negated provided
homeisp.net also runs an SPF/RMX compliant system when receiving email.
I believe that an forwarding relationship of this type should only occur
because the ultimate destination of the message intends to collect mail from
the additional contact address whether it be mailing list or forwarding
relationship. In other words alice should have to 'choose' to listen at that
address in the first place.
This is a consent relationship. One of the biggest net.problems to hit the
blacklists was how to deal with outright malicious complaints about mailing
list senders. At the FTC workshop Cindy Cohen described an organized
campaign to get moveon.org blacklisted. People subscribed to the list simply
so that they could report it to their ISP as spam.
The problem is that even though Alice subscribed to the list the incomming
email infrastructure does not know that this happened.
I do not like he-said-she-said problems. This one is easy to deal with,
simply attach a proof of consent to every message the forwarding
relationship generates. The proof can be generated during the original
subscription opt-in process.
Honestly after reading everything and having ran several mailing
lists I would think the easiest solution is to simple have the mailing
list software sign and archive the original confirmation email which
could be presented as proof. Clean, simple and much less headache than
trying to implement a scheme like this.
All we need to do to deploy this is to update the mailing list software C/R
module and then update the spam filters.
Not really, as I read the proposal it would require updates to
mailing lists as well as the MTA itself. This would not be as trivial a
task as you make it out to be. You also mention later in the proposal
that standardization of the MAC algorithm need not be done so long as
sender and received use the same one which is doubtful to happen without
standardization.
This is similar in concept to SRS but avoids the hokey address
transformations which I think confuse the end user. Every time my wife sees
something unusual in her email she demands a 30 minute consultation and an
explanation of why it is happening. She does not accept the fact that it is
futile to expect a computer whose fundamental operations are based on
quantum mechanics to behave in a deterministic manner. 'Thats just the way
the wave function collapsed today' is not considered acceptable. So I don't
like specs that do things that might confuse end users.
Phill
I'm not sure where you're coming with this arguement of SRS as
SRS modifies the Return-path: not the From: so it should be nominally
visible to a novice that would have trouble grasping it. My nearly
computer illiterate girlfriend has no problems with the fact my mail
servers use SRS as it's almost completly invisible to her. I just don't
follow the logic you're trying to present.
Another point you fail to acknowledge is that most mailing list
software already does actions similar to SRS with VERP when it sends the
mail out for delivery to the subscribers. Are you than trying to say
that VERP is any less confusing than SRS which follow a similar
principle but add a cryptographic verfication hash? I find SRS far more
verfiable than VERP by any standard.
Regards,
Jeremy