On Thu, 15 Dec 2016 22:35:10 +0000 Martin Gregorie wrote: > On Thu, 2016-12-15 at 22:19 +0000, RW wrote: > > > If you are using getmail/fetchmail it commonly just works. SA has > > explicit support for fetchmail, and getmail headers are unparseable. > > Either way there is typically a chain of private and localhost IP > > addresses up to the MX server. > > > Yes, that's been my experience with both fetchmail and getmail. I used > to use fetchmail until its habit of 'accidentally' leaving mail its > read but forgotten to delete in the source mailbox. Forever. > Eventually this annoyed me enough make the switch to getmail, which > hasn't caused me any problems at all. > > I haven't noticed any problems arising from getmail's 'unparseable > headers': in fact I hadn't noticed that they weren't being processed. > Which brings me to the question I wanted to raised in this (renamed) > thread: > > What would we gain if getmail generated headers were parsed?
The unparseable header breaks ALL_TRUSTED, but that doesn't really matter for a retriever. I don't recall any other practical difference. Making SA parse the header normally is a really bad idea because the public IP address of the POP/IMAP server will break the chain of trust, requiring trusted_network to be set explicitly. The fetchmail support causes the received header parsing to restart on the next header down. > IOW, should I raise a bug or would I just be wasting my and other > peoples, time? If it would not be a waste of time, should the bug be > raised against getmail or SA? There is a bug report with a patch to make the fetchmail support generic to all POP/IMAP, but it's not been committed. It doesn't make much difference for getmail. There might possibly be other retriever software that could benefit, although they're likely to be unparseble like getmail.
