aboutsummaryrefslogtreecommitdiffstats
path: root/contrib/ip-up
blob: 542448d9c464746492c09605797478947060f677 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
From James.Stevens@jrcs.co.uk  Mon Aug 25 18:11:36 1997
Return-Path: <James.Stevens@jrcs.co.uk>
Received: from locke.ccil.org (snark [10.0.2.15])
	by snark.thyrsus.com (8.8.5/8.8.5) with ESMTP id SAA10394
	for <esr@snark.thyrsus.com>; Mon, 25 Aug 1997 18:11:34 -0400
Received: (from slist@localhost)
	by locke.ccil.org (8.8.5/8.8.5) id GAA17071
	for esr; Mon, 18 Aug 1997 06:17:07 -0500 (EST)
Resent-Date: Mon, 18 Aug 1997 06:17:07 -0500 (EST)
X-Authentication-Warning: locke.ccil.org: slist set sender to fetchmail-friends-request@ccil.org using -f
X-NiNLog: [James.Stevens@jrcs.co.uk] [<fetchmail-friends@locke.ccil.org>] [199708180955.KAA04988]
Message-ID: <33F81C2D.AB822BBB@jrcs.co.uk>
Date: Mon, 18 Aug 1997 10:55:57 +0100
From: James Stevens <James.Stevens@jrcs.co.uk>
Reply-To: James.Stevens@jrcs.co.uk
Organization: JRCS Ltd
X-Mailer: Mozilla 4.01 [en] (Win95; I)
MIME-Version: 1.0
To: "fetchmail-friends@locke.ccil.org" <fetchmail-friends@locke.ccil.org>
Subject: A Little Tip...
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"lhVgRB.A.FFE.bxC-z"@locke.ccil.org>
Resent-From: fetchmail-friends@ccil.org
X-Mailing-List: <fetchmail-friends@ccil.org> archive/latest/725
X-Loop: fetchmail-friends@ccil.org
Precedence: list
Resent-Sender: fetchmail-friends-request@ccil.org
Status: RO

Seeing Eric tip us that we could run a "fetchmail -quit" in the
"ip-down" script, I thougt it would be neat to run a fetchmail
collection in the "ip-up" script. That way mail is collected
automatically every time I am connecting to Internet for whatever reason
(I use "diald" to automatically manage my connection).

However, it did not work. It hung right after the POP3 login. I tracked
this down to the fact that the "pppd" masks a wide range of signals and
this means a time-out does not kick in. As I run the "ip-up" script in
"bash" this masking is inheritied by "fetchmail".

So, I wrote a silly little "C" program that unmasks all signals and then
runs a command of you choice (in this case fetchmail). This is the code
for that program :-

#include <stdio.h>
#include <signal.h>

main(int argc,char * argv[])
{
sigset_t set;

    if (argc>1)
        {
        sigfillset(&set);
        sigprocmask(SIG_UNBLOCK,&set,NULL);
        system(argv[1]);
        }
}

I call it "allsigs". So, now in my "ip-up" I have the line :-

allsigs "fetchmail -f /etc/fetahmail"

Note the quotes as "allsigs" only looks at argv[1]. I guess this
unmasking of all signals could be added into "fetchmail" ?

James
class="na">content="Updated design notes on fetchmail." /> <meta name="keywords" content="fetchmail, POP, POP2, POP3, IMAP, ETRN, ODMR, remote mail" /> <style type="text/css"> /*<![CDATA[*/ h1.c1 {text-align: center} /*]]>*/ </style> </head> <body> <table width="100%" cellpadding="0" summary="Canned page header"> <tr> <td width="30%">Back to <a href="index.html">Fetchmail Home Page</a></td> <td width="30%" align="right">$Date: 2003/02/28 11:26:47 $</td> </tr> </table> <hr /> <h1 class="c1">Design Notes On Fetchmail</h1> <h2>Introduction</h2> <p>This document is supposed to complement <a href="esrs-design-notes.html">Eric S. Raymond's (ESR's) design notes.</a> The new maintainers don't agree with some of the decisions ESR made previously, and the differences and new directions will be laid out in this document. It is therefore a sort of a TODO document, until the necessary code revisions have been made.</p> <h2>Security</h2> <p>Fetchmail was handed over in a pretty poor shape, security-wise. It will happily talk to the network with root privileges, use sscanf() to read remotely received data into fixed-length stack-based buffers without length limitation and so on. A full audit is required and security concepts will have to be applied. Random bits are:</p> <ul> <li>code talking to the network does not require root privileges and needs to run without root permissions</li> <li>all input must be validated, all strings must be length checked, all integers range checked</li> <li>all types will need to be reviewed whether they are signed or unsigned</li> </ul> <h2>SMTP forwarding</h2> <p>Fetchmails multidrop and rewrite options will process addresses received from remote sites. Special care must be taken so these features cannot be abused to relay mail to foreign sites.</p> <p>ESR's attempt to make fetchmail use SMTP exclusively failed, fetchmail got LMTP and --mda options &ndash; the latter has a lot of flaws unfortunately, is inconsistent with the SMTP forwarder and needs to be reviewed and probably bugfixed. --mda doesn't properly work with multiple recipients, it cannot properly communicate errors and is best avoided for now.</p> <h2>Server-side vs. client-side state.</h2> <h3>Why we need client-side tracking</h3> <p>ESR asserted that server-side state were essential and those persons repsonsible for removing the LAST command from POP3 deserved to suffer. ESR is right in stating that the POP3 UID tracks which messages have been read <em>by this client</em> &ndash; and that is exactly what we need to do.</p> <p>If fetchmail is supposed to retrieve all mail from a mailbox reliably, without being disturbed by someone occasionally using another client on another host, or a webmailer, or similar, then <em>client</em>-side tracking of the state is indispensable. This is also needed to match behavior to ETRN and ODMR.</p> <h3>Present and future</h3> <p>Fetchmail supports client-side state in POP3 if the UIDL option is used (which is strongly recommended). Similar effort needs to be made to track IMAP state by means of UIDVALIDITY and UID.</p> <p>This will also mean that the UID handling code be revised an perhaps use one file per account or per folder.</p> <h2>Concurrent queries/concurrent fetchmail instances</h2> <p>ESR refused to make fetchmail query multiple hosts or accounts concurrently, on the grounds that finer-grained locks would be hard to implement portably.</p> <p>The idea of using one file per folder or account to track UIDs on the client-side will make solving this locking problem easy &ndash; the lock can be placed on the UID file instead.</p> <h2>Multidrop issues</h2> <p>Fetchmail tries to guess recipients from headers that are not routing relevant, for instance, To:, Cc:, or Resent-headers (which are rare anyways). It is important that fetchmail insists on the real envelope operation for multidrop. This is detailed in <a href="http://home.pages.de/~mandree/mail/multidrop">my article &quot;Requisites for working multidrop mailboxes&quot;</a>.</p> <p>As Terry Lambert pointed out in the FreeBSD-arch mailing list on 2001-02-17 under the subject "UUCP must stay; fetchmail sucks", fetchmail performs DNS MX lookups to determine domains for which multidrop is valid, on the assumption that the receiving SMTP host upstream were the same as the IMAP or POP3 server.</p> <hr /> <table width="100%" cellpadding="0" summary="Canned page footer"> <tr> <td width="30%">Back to <a href="index.html">Fetchmail Home Page</a></td> <td width="30%" align="right">$Date: 2003/02/28 11:26:47 $</td> </tr> </table> <br clear="left" /> <address>Matthias Andree <a href="mailto:matthias.andree@gmx.de">&lt;matthias.andree@gmx.de&gt;</a></address> </body> </html>