From: "Frank Ellermann" <nobody(_at_)xyzzy(_dot_)claranet(_dot_)de>
Hector Santos wrote:
As an author of a list server, I prefer to STRIP the
signature when allowed to avoid tampering with the many
options already offered to the list owner.
If you tamper with the message that's your best choice. But
ordinary lists don't tamper with messages, they redistribute
them as is, adding their List header fields, and using their
own Return-Path for automatical handling of errors.
Just to be clear, I was referring with screwing around with all the
existing options that a sysop traditionally desires in mailing list
based distributions.
Right, we have the "thin, slim and fat" models. Again, these are all
list sysops preferences.
Sympa also adds an Errors-To reflecting the Return-Path, and
that's the main case where DKIM must work transparently, for
unmodified redistributed mails.
We are talking body content mostly, not the headers, or network control
lines. Our LS also adds Error-To. No doubt, we desperately need a new
WG for LIST SERVERS. There are many old issues that needs to get
resolved. Everyone is designing and operating on a BCP mode and mostly
based on the original LISTSERV <tm> product.
Strip old signature or similar recipes are hardcore gateways
stuff, not be part of normal DKIM procedures. Gateway operators
are supposed to know what they do.
Well, a LS can be viewed as a GATEWAY, a gate from a 1 to 1 Email
Protocol to a 1 to Many "Groupware" system. That's part of the design
conflictive issues we deal with all the time. Sure, GATES usually deal
with heterogeneous networks or formats, but for all intent and purposes,
the way we use List servers today is basically KLUDGING email to be a
"Groupware" conference systems.
The ultimate question is, who "owns" or has control of the message. Once
the message is submitted to a list or MDA (final destination) for the
matter, many will argue, including myself, the LIST server does as a
gate. The message author has accomplished its goal of submitting a
message to an (list) address. That part is completed. After that, he
has no control of what happens and for the most part, NO say about the
storage, transformation presentation and/or distribution.
[Side Bar: Traditionally, based on US ECPA precedence already
established the storage owner does the email property. However,
traditionally not for passthrus (including an ISP hosting sending USER
outbound mail) That is one reason why "thou shall not tamper with
passthrus" exist . But there is a appeals case right now that is
challenging this in regards to SNIFFING passthru mail to spy on
competitor content information. The STORAGE ownership status (temporary
as a passthru) prevailed in the original case. This is being currently
appealed. It will probably reach the supreme court, as it should.]
All in all, there is only two things you have to worry (to be safe)
about when it comes to possible US ECPA conflicts:
- don't change the meaning of the message
- don't censor it.
But the US Congress already relaxed this too in 2000 to address the
Mommy market (Kiddy Porn) and to encourage the Mail Filtering Technology
market. This tort-reform protection is for PUBLISHERS of information,
not PROVIDERS. But the law specifically includes "Good Samaritan"
provisions which basically says "don't go crazy with this power."
Note much to the chagrin of Levine, this has nothing to do with
"Playing Lawyer" but rather understanding the laws and basic engineering
ethics as it applies to your business and product lines.
o=? WEAK (signature optional, no third party)
Oops, there it is, when I checked the SSP draft some hours ago
I missed this. What does WEAK mean for an _unsigned_ mail at
a third party willing to sign it ?
To me, if is SSP is suppose to define what a DKIM/SSP compliant mail
processor is suppose to do, it means it can't sign it.
WEAK, strip, do not sign
Stripping a valid signature makes no sense for redistributors.
Well, to maintain the transport consistency, it does. Whether it implies
some other possible "no-no", that's a different either. As of today,
we are not in the business of stripping stuff. Well, I take that back.
It exist and I predict it will get worst, in the area of Ad-Ware email.
Some receivers are already stripping this junk. Vendors that have been
doing this have been swamp with tortious interference lawsuits and if
they keep it up, smarter receivers, especially MUA will simply filter
this non-original added junk out.
That's only necessary if the original mail is mutilated beyond
recognition, the forged / broken / inconvenient (pick what you
like) cases.
Probably.
Frank, if you just look at what SSP is (right or wrong), what it means,
you can sit down and design the interface specs for your mail
processors.
If the final issue is "Well, its too much of a change for everyone to
realistically do", well, that's a different issue.
So far, it really isn't that bad IMO.
Ultimately, it will be the DKIM owner that is going to define what
happens. If he is blindly uses his new "marked" DKIM domain in public,
well, at some point, he will have trouble.
Exploiters will simply look for receivers that do not support DKIM and
blast away at this sites with both non-signed and signed, forged or
otherwise signatures. That isn't going to change until DKIM is widely
adopted, and even then, they will continue to look for non-DKIM sites,
just like the original CODE-RED virus continued to look for unpatched
IIS machines until eventually it was negligible. It took atleast 3-4
years before it became insignificant.
If anything, it is the realization by hackers that tells them it is
"worth" trying out a hack because there will always be enough of a
legacy market to exploit.
So to me, we need to go strong with DKIM/SSP and be very careful about
the relaxation of the protocol. Either you support it or your don't.
No in-between.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
ietf-dkim mailing list
http://dkim.org