From mboxrd@z Thu Jan 1 00:00:00 1970 Received: by 10.90.117.16 with SMTP id p16cs620748agc; Thu, 15 Oct 2009 08:29:40 -0700 (PDT) Received: by 10.224.43.164 with SMTP id w36mr161499qae.336.1255620580272; Thu, 15 Oct 2009 08:29:40 -0700 (PDT) Return-Path: Received: from rubyforge.org (rubyforge.org [205.234.109.19]) by mx.google.com with ESMTP id 6si325920qyk.105.2009.10.15.08.29.40; Thu, 15 Oct 2009 08:29:40 -0700 (PDT) Received-SPF: pass (google.com: domain of sup-talk-bounces@rubyforge.org designates 205.234.109.19 as permitted sender) client-ip=205.234.109.19; Authentication-Results: mx.google.com; spf=pass (google.com: domain of sup-talk-bounces@rubyforge.org designates 205.234.109.19 as permitted sender) smtp.mail=sup-talk-bounces@rubyforge.org Received: from rubyforge.org (rubyforge.org [127.0.0.1]) by rubyforge.org (Postfix) with ESMTP id EC52A121827D; Thu, 15 Oct 2009 11:29:39 -0400 (EDT) Received: from entry.masanjin.net (masanjin.net [209.20.72.13]) by rubyforge.org (Postfix) with ESMTP id 537931978284 for ; Thu, 15 Oct 2009 11:29:30 -0400 (EDT) Received: from w by entry.masanjin.net with local (Exim 4.69) (envelope-from ) id 1MySGg-0002xd-2Z for sup-talk@rubyforge.org; Thu, 15 Oct 2009 08:29:30 -0700 From: William Morgan To: sup-talk In-reply-to: <1255615018-sup-5653@midna.zekjur.net> References: <1255603625-sup-2558@midna.zekjur.net> <1255614431-sup-5910@masanjin.net> <1255615018-sup-5653@midna.zekjur.net> Date: Thu, 15 Oct 2009 08:29:29 -0700 Message-Id: <1255620476-sup-8113@masanjin.net> User-Agent: Sup/git Subject: Re: [sup-talk] About faking message IDs X-BeenThere: sup-talk@rubyforge.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: User & developer discussion of Sup List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sup-talk-bounces@rubyforge.org Errors-To: sup-talk-bounces@rubyforge.org Reformatted excerpts from Michael Stapelberg's message of 2009-10-15: > No, in my case it did not. The reason for that is calling "deliver" > directly, that is without talking SMTP to a mailserver. Thus, no > headers are getting added. Surely this is a corner case, but I think > it will cause headache for system administrators running into this > one, if they notice it all (overwriting messages is quite dangerous). Ok. I think it's fine to generate the message id via another mechanism, e.g. the way we do it in edit-message-mode ("<#{Time.now.to_i}-sup-#{rand 10000}@#{hostname}"). -- William _______________________________________________ sup-talk mailing list sup-talk@rubyforge.org http://rubyforge.org/mailman/listinfo/sup-talk