fetchmail
1
Return-Path:
Resent-Sender: (ignored if it doesn't contain an @ or !)
Sender: (ignored if it doesn't contain an @ or !)
Resent-From:
From:
Reply-To:
Apparently-From:
The originating address is used for logging, and to set the MAIL FROM address when forwarding to SMTP. This order is intended to cope gracefully with receiving mailing list messages in multidrop mode. The intent is that if a local address doesn't exist, the bounce message won't be returned blindly to the author or to the list itself, but rather to the list manager (which is less annoying). In multidrop mode, destination headers are processed as follows: First, fetchmail looks for the Received: header (or whichever one is specified by the `envelope' option) to determine the local recipient address. If the mail is addressed to more than one recipient, the Received line won't contain any information regarding recipient addresses. Then fetchmail looks for the Resent-To:, Resent-Cc:, and Resent-Bcc: lines. If they exists, they should contain the final recipients and have precedence over their To:/Cc:/Bcc: counterparts. If the Resent-* lines doesn't exist, the To:, Cc:, Bcc: and Apparently-To: lines are looked for. (The presence of a Resent-To: is taken to imply that the person referred by the To: address has already received the original copy of the mail).
Basic format is: poll SERVERNAME protocol PROTOCOL username NAME password PASSWORD Example: poll pop.provider.net protocol pop3 username "jsmith" password "secret1" Or, using some abbreviations: poll pop.provider.net proto pop3 user "jsmith" password "secret1" Multiple servers may be listed: poll pop.provider.net proto pop3 user "jsmith" pass "secret1" poll other.provider.net proto pop2 user "John.Smith" pass "My^Hat" Here's a version of those two with more whitespace and some noise words:
poll pop.provider.net proto pop3
user "jsmith", with password secret1, is "jsmith" here;
poll other.provider.net proto pop2:
user "John.Smith", with password "My^Hat", is "John.Smith" here;
This version is much easier to read and doesn't cost significantly more (parsing is done only once, at startup time). If you need to include whitespace in a parameter string, enclose the string in double quotes. Thus:
poll mail.provider.net with proto pop3:
user "jsmith" there has password "u can't krak this"
is jws here and wants mda "/bin/mail"
You may have an initial server description headed by the keyword `defaults' instead of `poll' followed by a name. Such a record is interpreted as defaults for all queries to use. It may be overwritten by individual server descriptions. So, you could write:
defaults proto pop3
user "jsmith"
poll pop.provider.net
pass "secret1"
poll mail.provider.net
user "jjsmith" there has password "secret2"
It's possible to specify more than one user per server (this is only likely to be useful when running fetchmail in daemon mode as root). The `user' keyword leads off a user description, and every user specification in a multi-user entry must include it. Here's an example:
poll pop.provider.net proto pop3 port 3111
user "jsmith" with pass "secret1" is "smith" here
user jones with pass "secret2" is "jjones" here keep
This associates the local username `smith' with the pop.provider.net username `jsmith' and the local username `jjones' with the pop.provider.net username `jones'. Mail for `jones' is kept on the server after download. Here's what a simple retrieval configuration for a multi-drop mailbox looks like:
poll pop.provider.net:
user maildrop with pass secret1 to golux 'hurkle'='happy' snark here
This says that the mailbox of account `maildrop' on the server is a multi-drop box, and that messages in it should be parsed for the server user names `golux', `hurkle', and `snark'. It further specifies that `golux' and `snark' have the same name on the client as on the server, but mail for server user `hurkle' should be delivered to client user `happy'. Here's an example of another kind of multidrop connection:
poll pop.provider.net localdomains loonytoons.org toons.org:
user maildrop with pass secret1 to * here
This also says that the mailbox of account `maildrop' on the server is a multi-drop box. It tells fetchmail that any address in the loonytoons.org or toons.org domains (including subdomain addresses like `joe@daffy.loonytoons.org') should be passed through to the local SMTP listener without modification. Be careful of mail loops if you do this! Here's an example configuration using ssh and the plugin option. The queries are made directly on the stdin and stdout of imapd via ssh. Note that in this setup, IMAP authentication can be skipped.
poll mailhost.net with proto imap:
plugin "ssh %h /usr/sbin/imapd" auth ssh;
user esr is esr here
Also, note that in multidrop mode duplicate mails are suppressed. A piece of mail is considered duplicate if it has the same message-ID as the message immediately preceding and more than one addressee. Such runs of messages may be generated when copies of a message addressed to multiple users are delivered to a multidrop box. Header vs. Envelope addresses The fundamental problem is that by having your mailserver toss several peoples' mail in a single maildrop box, you may have thrown away potentially vital information about who each piece of mail was actually addressed to (the `envelope address', as opposed to the header addresses in the RFC822 To/Cc/Bcc headers). This `envelope address' is the address you need in order to reroute mail properly. Sometimes fetchmail can deduce the envelope address. If the mailserver MTA is sendmail and the item of mail had just one recipient, the MTA will have written a `by/for' clause that gives the envelope addressee into its Received header. But this doesn't work reliably for other MTAs, nor if there is more than one recipient. By default, fetchmail A slight variation of the `X-Envelope-To' header is the `Delivered-To' put by qmail to avoid mail loops. It will probably prefix the user name with a string that normally matches the user's domain. To remove this prefix you can use the -Q or `qvirtual' option. Sometimes, unfortunately, neither of these methods works. When they all fail, fetchmail must fall back on the contents of To/Cc/Bcc headers to try to determine recipient addressees -- and these are not reliable. In particular, mailing-list software often ships mail with only the list broadcast address in the To header. When fetchmail cannot deduce a recipient address that is local, and the intended recipient address was anyone other than fetchmail's invoking user, mail will get lost. This is what makes the multidrop feature risky. A related problem is that when you blind-copy a mail message, the Bcc information is carried only Good Ways To Use Multidrop Mailboxes Bad Ways To Abuse Multidrop Mailboxes Multidrop mailboxes and fetchmail serving multiple users in daemon mode do not mix. The problem, again, is mail from mailing lists, which typically does not have an individual recipient address on it. Unless fetchmail can deduce an envelope address, such mail will only go to the account running fetchmail (probably root). Also, blind-copied users are very likely never to see their mail at all. If you're tempted to use fetchmail to retrieve mail for multiple users from a single mail drop via POP or IMAP, think again (and reread the section on header and envelope addresses above). It would be smarter to just let the mail sit in the mailserver's queue and use fetchmail's ETRN or ODMR modes to trigger SMTP sends periodically (of course, this means you have to poll more frequently than the mailserver's expiry period). If you can't arrange this, try setting up a UUCP feed. If you absolutely must Speeding Up Multidrop Checking This is the safest but also slowest method. To speed it up, pre-declare mailserver aliases with `aka'; these are checked before DNS lookups are done. If you're certain your aka list contains all DNS aliases of the mailserver (and all MX names pointing at it) you can declare `no dns' to suppress DNS lookups entirely and only
The exit codes returned by fetchmail are as follows:
If the environment variable FETCHMAILHOME is set to a valid and existing directory name, the .fetchmailrc and .fetchids and .fetchmail.pid files are put there instead of in the invoking user's home directory (and lose the leading dots on their names). The .netrc file is looked for in the the invoking user's home directory regardless of FETCHMAILHOME's setting.
If fetchmail is running in daemon mode as non-root, use SIGUSR1 to wake it (this is so SIGHUP due to logout can retain the default action of killing it). Running fetchmail in foreground while a background fetchmail is running will do whichever of these is appropriate to wake it up.
The RFC822 address parser used in multidrop mode chokes on some @-addresses that are technically legal but bizarre. Strange uses of quoting and embedded comments are likely to confuse it. In a message with multiple envelope headers, only the last one processed will be visible to fetchmail. To get around this, use a mailserver-side filter that consolidates the contents of all envelope headers into a single one (procmail, mailagent, or maildrop can be programmed to do this fairly easily). Use of some of these protocols requires that the program send unencrypted passwords over the TCP/IP connection to the mailserver. This creates a risk that name/password pairs might be snaffled with a packet sniffer or more sophisticated monitoring software. Under Linux and FreeBSD, the --interface option can be used to restrict polling to availability of a specific interface device with a specific local or remote IP address, but snooping is still possible if (a) either host has a network device that can be opened in promiscuous mode, or (b) the intervening network link can be tapped. We recommend the use of ssh(1) tunnelling to not only shroud your passwords but encrypt the entire conversation. Use of the %F or %T escapes in an mda option could open a security hole, because they pass text manipulable by an attacker to a shell command. Potential shell characters are replaced by `_' before execution. The hole is further reduced by the fact that fetchmail temporarily discards any suid privileges it may have while running the MDA. For maximum safety, however, don't use an mda command containing %F or %T when fetchmail is run from the root account itself. Fetchmail's method of sending bouncemail and spam bounces requires that port 25 of localhost be available for sending mail via SMTP. If you modify a ~/.fetchmailrc while a background instance is running and break the syntax, the background instance will die silently. Unfortunately, it can't die noisily because we don't yet know whether syslog should be enabled. On some systems, fetchmail dies quietly even if there is no syntax error; this seems to have something to do with buggy terminal ioctl code in the kernel. The -f - option (reading a configuration from stdin) is incompatible with the plugin option. The UIDL code is generally flaky and tends to lose its state on errors and line drops (so that old messages are re-seen). If this happens to you, switch to IMAP4. The `principal' option only handles Kerberos IV, not V. Send comments, bug reports, gripes, and the like to the fetchmail-friends list <fetchmail-friends@lists.ccil.org>. An HTML FAQ is available at the fetchmail home page; surf to http://www.catb.org/~esr/fetchmail or do a WWW search for pages with `fetchmail' in their titles.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
