From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/36425 Path: main.gmane.org!not-for-mail From: prj@po.cwru.edu (Paul Jarc) Newsgroups: gmane.emacs.gnus.general Subject: Re: Sender header? Date: 25 May 2001 14:16:46 -0400 Sender: prj@multivac.cwru.edu Message-ID: References: <01May23.141128edt.115245@gateway.intersys.com> <01May24.115917edt.115250@gateway.intersys.com> <01May24.143521edt.115214@gateway.intersys.com> <01May24.153439edt.115213@gateway.intersys.com> <01May24.163305edt.115259@gateway.intersys.com> <01May24.172056edt.115272@gateway.intersys.com> NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1035172011 8507 80.91.224.250 (21 Oct 2002 03:46:51 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 21 Oct 2002 03:46:51 +0000 (UTC) Return-Path: Original-Received: (qmail 18028 invoked by alias); 25 May 2001 18:16:46 -0000 Original-Received: (qmail 18023 invoked from network); 25 May 2001 18:16:46 -0000 Original-Received: from multivac.student.cwru.edu (HELO multivac.cwru.edu) (261@129.22.96.25) by gnus.org with SMTP; 25 May 2001 18:16:46 -0000 Original-Received: (qmail 29238 invoked by uid 500); 25 May 2001 18:17:08 -0000 Mail-Followup-To: ding@gnus.org Original-To: ding@gnus.org In-Reply-To: (Harry Putnam's message of "25 May 2001 10:50:16 -0700") User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7 Original-Lines: 62 Xref: main.gmane.org gmane.emacs.gnus.general:36425 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:36425 Harry Putnam writes: > prj@po.cwru.edu (Paul Jarc) writes: >> > Currently I've told gnus to stick my IP smtp server address in >> > Message-ID. >> >> Don't do that unless you control the SMTP server, and know that it >> won't generate Message-IDs using that same RHS. See my other message >> for more details. > > Now I'm really confused.. > Wait... shouldn't that smtp server AlWAYS use the same rhs? Probably. But if you control it, you could configure it to do otherwise. The main principle is that two different hosts should use two different domain-like things for their Message-IDs. So if you're using your SMTP server's hostname to generate Message-IDs on a different host, then you should make sure that the SMTP server doesn't use the same thing. If you don't control the SMTP server, then you can't ensure this, and so you should use something else on your other host. > The machine has a name like (/etc/hosts entry): > reader.local.lan 192.168.xx.xxx reader > There must be several (100/1000 ?) that could possibly have that FQDN. > How is this uniqueness obtained? Normally - i.e., "normal" at the time Message-ID was designed - you'd have a static FQDN on the Internet, and you'd use that. If possible, you should set things up so that Message-IDs are generated by hosts with static FQDNs on the Internet, and those hosts should use (probably) their own FQDNs for the RHS. Hosts that don't have static FQDNs should pass along the message without a Message-ID, and the the host that has the static FQDN generate one. This may require special configuration on both sides. If you can't do that, then try to use the FQDN of a host with a static FQDN on the Internet and which you control, so you can tweak each of their generation algorithms, if necessary, to ensure that the two won't ever generate the same LHS by accident. If you can't do that, then you're stuck, and all you can do is make a best effort. Throw some entropy into the RHS (maybe something like o4igh2r3.username.this-does-not-exist.your-isp.com, where the first part is preferably different for each message), and explain to anyone who objects that Message-ID was not designed with your situation in mind, and this is the best you can do. > Hard to see how either of these can be guarranteed to be unique any > more than: > Message-ID: They can't, except that by convention, the RHS is at least based on the FQDN of the Internet host where the Message-ID was generated. If you stray too far from that convention, you run the risk of choosing the same clever insertion that someone else did. Stay as close to it as your situation allows - if you can use a host's FQDN, use it; otherwise, use your organization's domain name along with something which is unique in that context, etc. paul