Matijs van Zuijlen <[EMAIL PROTECTED]> writes: [...]
> One thing you might look into is not writing [EMAIL PROTECTED] in the > rwriting rule, but instead [EMAIL PROTECTED] Your mail program > will put that in the From: header, whereas fetchmail will put > [EMAIL PROTECTED], avoiding the rewrite (see below). *Note:* This is just a > guess. I have never tried this, I just told mutt and balsa what my real > e-mail address is. OK, that sounds like it might be the problem, haven't actually tried yet but will later today. >> So the basics are in place and working. I didn't like the way headers >> came out, not sure if it really matters, but I think it isn't rfc >> compliant this way. (I'll show and example below). > > They're great. And useful for examining your problem. That is true, so probably better to leave them alone. [...] > It *is* downloaded. It's just sent away again. See below. I see now. I hadn't caught that in my own investigation. Thanks. [...] >> Far as I have heard, those addresses should not leak out onto the >> internet, where they may be taken for legal (domain owned) addresses. > > They're just as they should be. The recieved headers don't care about > whether the adresses are private or not. Every server that the mail goes > through just puts its part in there. It should never touch the others. > Of course, this means that a human has to look at them to get them to > make sense, but that's just what we're doing. From the headers you can > see that the mail is just being sent back and forth between your box and > your ISP (note that fetchmail is mentioned twice). If your servers were Actually it is mentioned 3 times, but I hadn't noticed it until you pointed it out. > smart enough to remove all local info, it would be impossible to track > down what happened. OK, so I've had the wrong notion, and better to keep all info as it is put in. Thanks... this has gone a ways to improve my understanding of what happens and what is supposed to happen.
