Julian Elischer wrote:
> > See above. fetchmail + pop works fine. I've been get all of my envelope
> > information, and there is no worries.
> This has noty been the case where I have seen..
> This requires that you have a mailbox set up on the server which can
> 'encode' all of the envelope information (e.g. other delivery addresses)
> and that fetchmail can extract this information in such a way that it can
> reconstruct the original mail address information without getting it
> confused with the header infiormation within the mail headers, which of
> course should be completely ignored when it comes to delivery.
> Unfortunatly I have not see this done completely successfully.
> UUCP can do this with very little work and does it very well.
> (as if keeps the 'command' information separate from the
> "data" information).
> I"m not saying that this is not possible, just that it's very complicated
> to get right compared to a basic "out of the box" uucp connection that
> can do it completely correctly with almost no work...
Ricoh, Japan allowed me to dictate their SMTP/POP3 server setup
to them for use with the InterJet, which at the time was running
fetchmail for the "POP3 lookup" feature.
I was able to dictate single delivery of messages by their SMTP
server, which resulted in valid "for <user>" optional portions
of the "Received:" timestamp line.
The fetchmail in question included my patches to permit the
command line override of the seperate delivery/fanout machine
assuming that the delivery machine hosted the POP3 maildrop
(Eric Raymond did not respond to several emails where I tried
to get these patches included in fetchmail, as an overload of
an otherwise duplicate command line option).
Given this change to fetchmail, and the timestamp envelope
information, the single deliver did not exposed "Bcc:"
envelope data to anyone but the recipient who was "Bcc:"'ed.
So I can vouch for POP3 based domain fanout working in hundreds
of installations... IFF you and your ISP take special pains to
cooperate on both ends.
When we moved to the PMTA code, all of the fetchmail related
problems went away (a good cathedral beats a bazaar any day).
The IBM Web Connections NOC supported fanout delivery from
day one (of course, since I was the architect for that NOC).
> > 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.
> It doesn't even work well for static users in large configurations..
> as it requires a full queue scan. (some mail servers do this better
> than others).
Yes. 8-). David Wolfskill and I rewrote portions of sendmail
to support per domain mail queues, as you well know, and were
able to successfully support 100,000 domains on a single mail
server with a load of 400,000 messages per day.
Comparatively, Telenor had a SPARC Center 10000 that crashed
under a once-per-hour ETRN polling load for only 300 virtual
domains (without the sendmail changes we did).
I believe our patches for sendmail 8.9.3 are still up on the
Interestingly, Microsoft Exchange is one of the few commercial
SMTP servers that can handle more than a few hundred ETRN based
virtual domain instances. Go figure...
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message