From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/31804 Path: main.gmane.org!not-for-mail From: Nuutti Kotivuori Newsgroups: gmane.emacs.gnus.general Subject: Re: Gnus Access mail spool by ssh Date: 16 Jul 2000 18:11:57 +0300 Organization: Gnus Information Center Sender: owner-ding@hpc.uh.edu Message-ID: <873dlayurm.fsf@sonera.com> References: <87lmz7d93d.fsf@sonera.com> <87hf9vcsc6.fsf@sonera.com> <87em4yd75t.fsf@sonera.com> NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Trace: main.gmane.org 1035168172 16121 80.91.224.250 (21 Oct 2002 02:42:52 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 21 Oct 2002 02:42:52 +0000 (UTC) Return-Path: Original-Received: from fisher.math.uh.edu (fisher.math.uh.edu [129.7.128.35]) by mailhost.sclp.com (Postfix) with ESMTP id 20484D051E for ; Sun, 16 Jul 2000 11:20:19 -0400 (EDT) Original-Received: from sina.hpc.uh.edu (lists@Sina.HPC.UH.EDU [129.7.3.5]) by fisher.math.uh.edu (8.9.1/8.9.1) with ESMTP id KAC18006; Sun, 16 Jul 2000 10:16:46 -0500 (CDT) Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Sun, 16 Jul 2000 10:14:42 -0500 (CDT) Original-Received: from mailhost.sclp.com (postfix@sclp3.sclp.com [204.252.123.139]) by sina.hpc.uh.edu (8.9.3/8.9.3) with ESMTP id KAA18720 for ; Sun, 16 Jul 2000 10:14:28 -0500 (CDT) Original-Received: from quimby.gnus.org (quimby.gnus.org [193.69.4.139]) by mailhost.sclp.com (Postfix) with ESMTP id 16209D051E for ; Sun, 16 Jul 2000 11:15:03 -0400 (EDT) Original-Received: (from news@localhost) by quimby.gnus.org (8.9.3/8.9.3) id RAA32584 for ding@gnus.org; Fri, 14 Jul 2000 17:16:44 +0200 (CEST) Original-To: ding@gnus.org Original-Path: not-for-mail Original-Newsgroups: gnus.ding Original-Lines: 46 Original-NNTP-Posting-Host: kotivnu1-nb.ete.tele.fi Original-X-Trace: quimby.gnus.org 963587803 14971 131.177.214.96 (14 Jul 2000 15:16:43 GMT) Original-X-Complaints-To: usenet@quimby.gnus.org Original-NNTP-Posting-Date: 14 Jul 2000 15:16:43 GMT User-Agent: T-gnus/6.14.4 (based on Gnus v5.8.6) EMY/1.13.6 (Life is balance) FLIM/1.13.2 (Kasanui) APEL/10.2 MULE XEmacs/21.1 (patch 10) (Capitol Reef) (i386-debian-linux) Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:31804 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:31804 "Harry" == Harry Putnam writes: > Nuutti Kotivuori writes: > [...] > >> >> Well as pointed out, fetchmail does as it's told. For the very best >> solutions, it likes to use a local SMTP server, if not, then MDA, >> if not then maybe BSMTP delivery or whatever. That has nothing to >> do with this setup, it's just fetchmail configuration. > > In this case it is using local SMTP. > > [...] > >> Um. IMAP has multiple folder support. Find out how your IMAP server >> handles multiple folder and store the messages to a folder named >> remote for example. Then just pass folder option in your >> fetchmailrc. > > After cleaning up my fetchmail install but before studying up on > imap workings regarding `multiple folders' I just created a user > account for `laptop' on the parent machine. Forward copies of all > mail there, and access that spool with the method you've explained. > This works fine. > > One problem has cropped up and may be fetchmail specific but the > laptop fetchmail (version 5.4.1) seems to be eating the > `Return-Path: ' headers. > > Viewing the messages on parent machine in /var/mail/spool/laptop I > see those headers in tact. But once moved to the laptop those > headers are gone. The parent machine is fetching with > fetchmail-5.3.1-1. > > Could something in the methodology be causing this or do you think > it would be a fetchmail version issue? > > Do you see something similar? Um. Not a version issue I'd say. Think it might be defined behaviour even. There's a fetchmail option called 'invisible' which will try to make it invisible to the mda (normally it inserts received headers and the like). Also, no-bounce is worth looking into, since it's kinda tied in with return-path. -- Naked