I think that the DKIM mailing list story is a viable one. What mailing lists and forwarders are asked to do is no different from any other user. That is the key.
> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Hector Santos > Sent: Tuesday, October 18, 2005 8:43 PM > To: [email protected] > Subject: Re: [ietf-dkim] Re: Admilistrivia question > > > ----- Original Message ----- > From: "Frank Ellermann" <[EMAIL PROTECTED]> > To: <[email protected]> > > > > 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 > > _______________________________________________ ietf-dkim mailing list http://dkim.org
