Nate Williams wrote: > > POP and IMAP (I think) will lose all the envelope information, > > You've been listening to Terry too long. It's certainly not the case, > although I've decided to quit arguing with Terry, since it's an > excercise in futility. No matter what you say, he'll either change the > subject or simply overwhelm you with useless/unrelated material until > you simply abandon any hope of trying to give out useful information.
Alternately, you could also read the fetchmail documentation as to why it is not an MTA. Really, Nate, you should have received enough SPAM by now to know that the "From:", "To:", and "Cc:" headers have no bearing on who the message is delivered to. FWIW, I have ensured that this message will be delivered twice (once on the list, once on) to both you an Julian, on the basis of envelope information, even though this information will not show up in headers. Feel free to read RFC 821, RFC 2505, and RFC 2554 (rationale), with specific attention to what information is maintained or lost when leaving an RFC 821 transport, and the disposition of the "Bcc:" header on client to server submissions. > See above. fetchmail + pop works fine. I've been get all of my envelope > information, and there is no worries. Perhaps you aren't using it in "multidrop" mode, for virtual domain delivery? Otherwise your ISP is tunneling envelope information in the headers (e.g. qmail's "Delivered-To:" -- which the RFC's require to be named "X-Delivered-To:", but of course DJB is not known for following RFC's -- or an "X-Frontier-To:" or "X-Envelope-To:"). Tell me, is your mail compliant with the non-disclosure of "Bcc:" recipients requirement? If fetchmail doesn't strip the tunneling headers (it doesn't), then the headers disclose "Bcc:"'ed recipients to anyone who chooses to look. Alternately, your ISP has set "single delivery mode", so that the "Received:" timestamp line contains the optional "for <user>", which is left out if there are multiple recipients for the mail message, since to do otherwise would require duplication. And doing that would disable the duplicate supression in the SMTP server software (hmmm... I will "Bcc:" you at the fully qualified domain name as well -- let us all know if you get 3 instead of just 2 copies of this email... also let us know if you have a "for [EMAIL PROTECTED]" "Received:" timestamp line). If the latter, you should count yourself lucky that the ISP does not do domain fan out on one machine, and POP3 maildrop hosting on another: fetchmail includes the mail server from which you are retrieving the mail, since fetchmail erroneously assumes that this machine is a designated MX for your domain. If you are using tunneled information, you should count yourself luck that your ISP does the header insertion prior to other insertion, since fetchmail will blindly deliver to the first header it deems to be deliverable, rather than priority sorting which header it uses based on confidence. > For 'fetching' email, fetchmail is a very good solution. However, there > is also another fairly trivial solution that works well, *IF* you have a > static IP address. > > ETRN also is a good 'fetch' mechanism, if your ISP sets up MX records > for you. When you come up, you simply telnet into your ISP's mail > server, then type 'ETRN foobar.com', and it'll dump all your email to > the IP address of your static configuration. > > However, this won't work for roving users. Yeah, for that there's "ATRN", which is really pretty dumb, since we could have just changed the semantics of "ETRN" in the presence of authentication. Too bad there are no public implementations of "ATRN"; the only implementations I've heard of are the one at Qualcomm, and the one that Whistle did -- SURPRISE! That's where Julian and I worked! Alternately, of course, there's UUCP... pull methods frequently work much better than triggered push mechansims. PS: I'm surprised you didn't mention the "finger" or the "PPP linkup script" methods. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
