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', 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

Reply via email to