From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/65782 Path: news.gmane.org!not-for-mail From: Elias Oltmanns Newsgroups: gmane.emacs.gnus.general Subject: Re: Gnus generates an invalid To header Date: Mon, 26 Nov 2007 13:42:39 +0100 Message-ID: <87prxxw534.fsf@denkblock.local> References: <87tznbkgqs.fsf@member.fsf.org> <873autb65l.fsf@member.fsf.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1196081028 16260 80.91.229.12 (26 Nov 2007 12:43:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 26 Nov 2007 12:43:48 +0000 (UTC) To: ding@gnus.org Original-X-From: ding-owner+M14278@lists.math.uh.edu Mon Nov 26 13:43:55 2007 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.50) id 1IwdJT-0004nz-RC for ding-account@gmane.org; Mon, 26 Nov 2007 13:43:48 +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 1IwdJ5-0008Fk-Pr; Mon, 26 Nov 2007 06:43:23 -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 1IwdJ4-0008FS-Dd for ding@lists.math.uh.edu; Mon, 26 Nov 2007 06:43:22 -0600 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx2.math.uh.edu with esmtp (Exim 4.67) (envelope-from ) id 1IwdIx-0008Qo-TE for ding@lists.math.uh.edu; Mon, 26 Nov 2007 06:43:22 -0600 Original-Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1IwdIu-00035g-00 for ; Mon, 26 Nov 2007 13:43:12 +0100 Original-Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IwdIq-0007Q9-HW for ding@gnus.org; Mon, 26 Nov 2007 12:43:08 +0000 Original-Received: from pd9e86d01.dip.t-dialin.net ([217.232.109.1]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 26 Nov 2007 12:43:08 +0000 Original-Received: from eo by pd9e86d01.dip.t-dialin.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 26 Nov 2007 12:43:08 +0000 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 55 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: pd9e86d01.dip.t-dialin.net User-Agent: Gnus/5.110007 (No Gnus v0.7) Cancel-Lock: sha1:yWZXgrDqiIEaqgbERgBI0Tksnkw= X-Spam-Score: -2.6 (--) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:65782 Archived-At: Tassilo Horn wrote: > Reiner Steib writes: > > Hi Reiner, > >>> Reply-To: "kontakt@tieraerztliche-klinik.com" >>> From: >>> >>> When I want to reply to it (R or r) Gnus generates the following To >>> header: >>> >>> To: "kontakt@/usr/bin/idn: tld_check_4z: missing inputtieraerztliche-klinik.com" >> >> This looks like the output of the IDNA program (/usr/bin/idn). I >> don't have IDNA installed, so I get (disabling it does the same [1]): >> >> ,---- >> | To: "kontakt@tieraerztliche-klinik.com" >> `---- >> >> This is exactly the bogus Reply-To the sender requested. >> >> By edebugging `message-idna-to-ascii-rhs-1', I found that it calls >> (idna-to-ascii rhs) with `rhs' = "" because the right hand side of >> "tierklinikkaiserbergduisburg" is the empty string. Maybe message >> should just return the same header instead if calling `idna-to-ascii' >> if `rhs' is empty? > > With "the same header" you mean the complete bogus Reply-To header? I > don't think that would be good, because then it would possibly be sent > to a local user. And sending to a wrong recipient is much worse than > not sending at all. What Reiner suggests is fixing a bug on Gnus' part and a priori the right thing to do. Your concern is legitimate, but it is a feature request rather than a bug fix. After all, the sender is ultimately responsible for setting a valid Reply-To header and, by failing to do so, positively asks for trouble. Also, Reiner's suggestion doesn't even change anything on the MTA level since the non'comment part of both example headers (Reiner's and yours) are identical. That said, it might still be worthwhile to implement the feature you are asking for. I recollect two incidents where I tried to reply to emails only to find out that the Reply-To header was bogus. However, there seem to be too many ways to screw the Reply-To header in a way that results in a syntactically correct but effectively bogus header. If a user decides to use fully qualified email addresses only (after all, there is bbdb and auto completion), gnus can generally warn before shipping off messages to addresses without a domain part. This is about all I can think of right now to tacle this issue and its probably not a good default setting. Regards, Elias