From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/74602 Path: news.gmane.org!not-for-mail From: =?utf-8?Q?=C5=81ukasz?= Stelmach Newsgroups: gmane.emacs.gnus.general Subject: Re: [PATCH] private message id Date: Thu, 02 Dec 2010 00:16:57 +0100 Message-ID: <87pqtlw0ba.fsf%lukasz.stelmach@iem.pw.edu.pl> References: <87fwujreui.fsf%lukasz.stelmach@iem.pw.edu.pl> <87r5e22t87.fsf%lukasz.stelmach@iem.pw.edu.pl> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: dough.gmane.org 1291245465 28712 80.91.229.12 (1 Dec 2010 23:17:45 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 1 Dec 2010 23:17:45 +0000 (UTC) To: ding@gnus.org Original-X-From: ding-owner+M22960@lists.math.uh.edu Thu Dec 02 00:17:41 2010 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from util0.math.uh.edu ([129.7.128.18]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PNvvh-0004T6-Jr for ding-account@gmane.org; Thu, 02 Dec 2010 00:17:41 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by util0.math.uh.edu with smtp (Exim 4.63) (envelope-from ) id 1PNvvV-0007dA-Tq; Wed, 01 Dec 2010 17:17:29 -0600 Original-Received: from mx2.math.uh.edu ([129.7.128.33]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1PNvvU-0007cy-DC for ding@lists.math.uh.edu; Wed, 01 Dec 2010 17:17:28 -0600 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx2.math.uh.edu with esmtp (Exim 4.72) (envelope-from ) id 1PNvvG-0008W0-Fa for ding@lists.math.uh.edu; Wed, 01 Dec 2010 17:17:28 -0600 Original-Received: from lo.gmane.org ([80.91.229.12]) by quimby.gnus.org with esmtp (Exim 3.36 #1 (Debian)) id 1PNvvE-00074J-00 for ; Thu, 02 Dec 2010 00:17:12 +0100 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PNvvD-0004J2-Sj for ding@gnus.org; Thu, 02 Dec 2010 00:17:11 +0100 Original-Received: from 87-205-242-8.adsl.inetia.pl ([87.205.242.8]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 02 Dec 2010 00:17:11 +0100 Original-Received: from lukasz.stelmach by 87-205-242-8.adsl.inetia.pl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 02 Dec 2010 00:17:11 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 45 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 87-205-242-8.adsl.inetia.pl User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) Cancel-Lock: sha1:u8t1XSmwlZ2SCOka2o8b97TuhLw= X-Spam-Score: -1.9 (-) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:74602 Archived-At: Lars Magne Ingebrigtsen writes: > Łukasz Stelmach writes: > >> This is an option. However, there is the whole superseding code which >> looks like it should be there. So copying a function just to redefine >> two lines in it looks weird, doesn't it? > > It's really the message-unique-id and/or message-make-fqdn that need > redefinition, isn't it? Not exactly. Let me explain it step by step (and think aloud). By default you get: <87vd3dw1fh.fsf@some.host.fqdn> If you redefine message-unique-id you still get the same fqdn on every message you send regardless of the account (identity) you use. This makes them easy to associate. Conclusion message-unique-id is OK as it is let's change message-make-fqdn. Lets make message-make-fqdn return sender's address <87tyixw1au.fsf@lukasz.stelmach@iem.pw.edu.pl> It is invalid Message-ID because it comprises two `@' characters. The first `@' comes from message-make-message-id so either we redefine this function or substitute the second `@' with a character valid for a domain name. <87r5e1w15q.fsf@lukasz.stelmach-iem.pw.edu.pl> Now message-make-fqdn returns lukasz.stelmach-iem.pw.edu.pl which preserves ID's uniqueness. And it is a good Message-ID. In fact you in the latter case it's enough to set message-user-fqdn (but a function attached somewhere around message-send-hook is required to set it according to the From header, which in fact is equivalent work to redefinition of message-make-fqdn). However, in this particular case everything seems to work fine, it will only as long as no one expects it to return what its name means. That's my rationale for the patch. -- Miłego dnia, Łukasz Stelmach