----- 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