-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Hector Santos
Sent: Tuesday, October 18, 2005 8:43 PM
To: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] Re: Admilistrivia question
----- Original Message -----
From: "Frank Ellermann" <nobody(_at_)xyzzy(_dot_)claranet(_dot_)de>
To: <ietf-dkim(_at_)mipassoc(_dot_)org>
Hector Santos wrote:
Some list servers will force a Reply-To: header in the
distribution
to point to the mailing list address.
Horrible. Hopefully DKIM will put an end to all these unnecessary
manipulations of 3rd parties, it's bad enough when one user
(not here)
inserts a Reply-To list manually.
Frank, I can almost assure you, DKIM will not stop any LIST
SERVERS, or more importantly their operators, from doing what
they have been doing for decades.
This is this same unrealistic wish item the SPF-right <g>
have about decades old existing behavior of relays and/or
forwarders. In their eyes, SPF is not broken - Forwarders
are! Maybe so, maybe not, but you can't have it both ways.
It is what it is. The better technology works around ALL the
issues. The one attractive aspect of DKIM is that it
attempts removes the
forwarding issue. But it assumes non-altering middle ware.
A good assumption but it runs into a trouble when trying to
accomodate a groupware system.
This is done for MUA ergonomic reasons
Mail software trying to be smart is always a PITA. And
what you claim
to be "human nature" is your personal POV with your software, it's
completely different from my POV.
It has nothing to do with our "smart" software, but we do
accomolate a wide range of options and behaviors.
The natural MUA action is to click the REPLY "button" if you
want to reply to a direct 1-1 email mail system for which the
RFC-based MUA is designed for. Most public RFC-based MUA
have 2 (excluding IMAP) mail concepts:
SMTP/POP3 - Email 1 to 1
NEWS - Groupware-like, conference-like, 1 to many.
The problem with mailing list today, is that they are trying
to emulate groupware designs for which the MUA has no options
for. You don't have a 3rd reply option:
"Reply to Mailing List Address"
It isn't like advance MUA systems with IMAP or include an
"exchange" concept with backend hosting systems where you do
have an natural reply back to the group.
A case a point: Look at your favorite system - gmane. It
uses groupware
ideas to present a mailing list. The Nature Reply is not
back to the
AUTHOR, but back to the "system" or "conference" or "group"
So it is my POV for MY software, sure, but its based on
customer demands and the realities of the market place.
To resolve this, the list server may add/change the
Reply-To: to the mailing list address.
Maybe for those who explicitly want this (opt-in), with a
warning that
this means trouble for a real Reply-To sent by the author.
And the author should be WARNED when he first joins a list,
that he will be communicating in a "groupware" system and I
will venture, using pareto's principle, most users will
naturally expect this because that is what he or she joining
into. Right? However, at the other end (MUA), for newbies
(and even vets), they might find it unnatural with the reply concept.
Same issue as Sender-ID, touch one of the
2822 header fields in transit and what you get is havoc.
True, true. Headers and Body should not be altered,
especially in direct 1
to 1 email and passthru systems. But many will argue that
it is acceptable
to take responsibility for the email sent into a groupware
system where a new form distribution and ever increasing
altered presentable takes place.
If you join one of these systems, you can not expect it to be
a clean, unaltered EMAIL 1 to 1 transaction because it wasn't
a 1 to 1 email transaction.
In my view, the DKIM-right will be beating a dead horse
trying to use DKIM as the "stick" to change decades old list
server behaviors. This is like trying to hike across the
Florida Everglades thinking you might not get bit by
mosquitoes, snapped at by gators or wrapped up by a python. :-)
But as a vendor, I will look into it. I have to if I want to
support DKIM.
You can't ignore the conflicts it presents. So either it
will work or not
and even up being another bastard concept like SPF forwarding issues.
Personally, I think it will work better (for a mailing list)
as a STRIP/RESIGN signature BUT ONLY if the original system
allows it.
And by "working better" I am looking at it as a designer,
what will it take to make this DKIM system, as is, WORK
within a mailing list?
I brought up the issue that if this becomes a problem, you
might find domains being excluded from being used in a mailing list.
For example, it has crossed our minds that we might need an
List Server Subscription logic that double checks the email
domain of a new signup for SSP 3rd party signing allowance.
If the SSP indicates a EXCLUSIVE policy, the list server
might have to send a negative signup response:
Sorry, you can use this email domain for this mailing list
due to DKIM SSP Exclusive Policy. Use another email address
and domain.
So Frank, it isn't all cut and dry. We actually put some
thought into this.
:-)
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
ietf-dkim mailing list
http://dkim.org