Ingo Hohmann <[EMAIL PROTECTED]> writes: > On Tue, Feb 09, 1999 at 12:01:16AM +0100, Helge Hafting wrote: > > > > Well, maybe fetchmail gives up completely at the first > > broken message? > > At least, thats what it does here. > > > > But debian.virtual.de.host is my own system, and I am able to _MAIL_ to > > > [EMAIL PROTECTED], it appears in his spool file, only fetchmail > > > won't get it back...
One thing that may be relevant here is the fetchmail "smtphost" setting. By default, when fetchmail delivers mail it retrieves, the address it delivers to is the same as the local address that it was assigned when getting mail. An example: I have a box that connects via a ppp dialup line. When I connect, my machine is assigned an IP address in the range 128.220.222.*. For example, let's say I dial in and get 128.220.222.98. Then, when fetchmail connects to my mail server (128.220.2.5), it notices that the local end of the connection is at 128.220.222.98, and when it turns around and delivers the mail, it attempts to deliver it to 128.220.222.98. That is, fetchmail delivers the mail to my machine through the IP address associated with the ppp connection, instead of the localhost (127.0.0.1) address. (*) Now, since I don't trust the other people who use my ISP to not try to use my machine as a mail relay, my machine doesn't accept mail from IP addresses in the 128.220.222.* range. (In fact, my machine doesn't accept mail from anything but my own mini-network) Therefore, under the defaults, fetchmail will fail to be able to deliver mail since the fetchmail connection will appear to be coming from the IP address that my machine got when it dialed in. The default debian exim setup (which is, in my opinion, a good way to do things) refuses to allow non-local machines to deliver mail by just sending to the username, not to [EMAIL PROTECTED] The fix for this is to include the line: defaults smtphost localhost at the top of your .fetchmailrc file. This forces fetchmail to deliver mail to 127.0.0.1, which means that it will use the loopback network interface, which is guaranteed to be local. This means that my machine accepts the mail, and also means that under debian's default exim setup, delivery will be allowed to unqualified names. (*) delivery to localhost used to be the default. Why fetchmail's upstream authors changed the default (with only a small note hidden deep in the documentation) is completely beyond me - I can think of only very unusual reasons why you'd want the current default behavior, and many reasons why you'd want the old default behavior. Fetchmail's upstream authors have a history of introducing optional features which, while useful in some cases, will cause many installations to break, and then of enabling those features by default. I believe this to be evidence that the fetchmail author has taken his own writings on the benefits of bazaar-style development too seriously to impose enough sanity-checking control on fetchmail. (For those of you who don't know, Eric S. Raymond, fetchmail's upstream author, is the author of "The Cathedral and the Bazaar", which many consider to be the manifesto of the open source movement. "Fetchmail" is in fact the program used as a case study in that article) For further rantings about this and other tendencies in the development of fetchmail, see debian-devel for the past few days.
