instead of sending directly from the database (should always be on)
The Microsoft pod-person who revealed this information to me admitted that he couldn't find it anywhere in their public knowledge base.
Another specific problem we have seen with Exchange servers has as its symptom a response to LOGIN that says "NO Ambiguous Alias". Grant Edwards writes:
This means that Exchange Server is too f*&#ing stupid to figure out which mailbox belongs to you. Instead of actually keeping track of which inbox belongs to which user, it uses some half-witted, guess-o-matic heuristic to try to guess your mailbox name from your username.
In your case it doesn't work because your username maps to more than one mailbox. For some people it doesn't work because their username maps to zero mailboxes. This is yet another inept, lame, almost criminally negligent design decision from our friends in Redmond.
You've got several options:
But, the best option involves a tactical nuclear weapon (an old ASROC will do), pissing off a lot people who live downwind from Redmond, and your choice of any Linux, NetBSD, FreeBSD, or Solaris CD-ROM.
No special configuration is required, but OpenMail versions prior to 6.0 have an annoying bug similar to the big one in Microsoft Exchange. The message sizes it gives in the LIST are rounded to the nearest 1024 bytes. It also has a nasty habit of discarding headers it doesn't recognize, such as X- and Resent- headers.
As with M$ Exchange, the only real fix for these problems is to get a POP (or preferably IMAP) server that isn't brain-dead. OpenMail's project manager claims these bugs have been fixed in 6.0.
We've had a more recent report (December 2001) that the TOP command fails, returning only one line regrardless of its argument, on something identifying itself as "OpenMail POP3 interface".
The Novell GroupWise IMAP server would be better named GroupFoolish; it is (according to the designer of IMAP) unusably broken. Among other things, it doesn't include a required content length in its BODY[TEXT] response.
Fetchmail works around this problem, but we strongly recommend voting with your dollars for a server that isn't brain-dead. If you stick with code as shoddy as GroupWise seems to be, you will probably pay for it with other problems.
You can't. At least not if you want to be able to see attachments. InterChange has a bug similar to the MailMax server; it reports the message length with attachments but doesn't download them on TOP or RETR.
On Jan 9 2001, the people at InfiniteMail sent me mail informing me that their new 3.61.08 release of InterChange fixes this problem. I don't have any reports one way or the other yet.
You can't. At least not if you want to be able to see attachments. MailMax has a bug; it reports the message length with attachments but doesn't download them on TOP or RETR.
Also, we're told that TOP sometimes fails to retrieve the entire message even when enough lines have been specified. The MailMax developers have acknowledged this bug as of 4 May 2000, but there is no fix yet. If you must use this server, force RETR with the fetchall option.
The FTGate V2 server (and possibly older versions as well) has a
weird bug. It answers OK twice to a TOP request! Use the
fetchall option to force use of RETR and work around
First, make sure your fetchmail has the RPA support compiled in.
Stock fetchmail binaries (such as you might get from an RPM) don't.
You can check this by looking at the output of
-V; if you see the string "+RPA" after the version ID you're
good to go, otherwise you'll have to build your own from sources
(see the INSTALL file in the source distribution for
Give your CompuServe pass-phrase in lower case as your password. Add `@compuserve.com' to your user ID so that it looks like `user <UserID>@compuserve.com', where <UserID> can be either your numerical userID or your E-mail nickname. An RPA-enabled fetchmail will automatically check for csi.com in the POP server's greeting line. If that's found, and your user ID ends with `@compuserve.com', it will query the server to see if it is RPA-capable, and if so do an RPA transaction rather than a plain-text password handshake.
Warning: the debug (-v -v) output of fetchmail will show your pass-phrase in Unicode!
These two .fetchmailrc entries show the difference between an RPA and non-RPA configuration:
# This version will use RPA poll csi.com via "pop.site1.csi.com" with proto POP3 and options no dns user "CSERVE_USER@compuserve.com" there with password "CSERVE_PASSWORD" is LOCAL_USER here options fetchall stripcr # This version will not use RPA poll non-rpa.csi.com via "pop.site1.csi.com" with proto POP3 and options no dns user "CSERVE_USER" there with password "CSERVE_POP3_PASSWORD" is LOCAL_USER here options fetchall stripcr
You can get fetchmail to download the email for just one user from Demon Internet's POP3 server by giving it a username consisting of your Demon user name followed by your account name, with an at-sign between them.
For example, to download email for the user <email@example.com>, you could use the following .fetchmailrc file:
set postmaster "philh" poll pop3.demon.co.uk with protocol POP3: user "philh@vision25" is philh
Demon Internet's SDPS service is an implementation of POP3. All messages have a Received: header added when they enter the maildrop, like this:
Received: from punt-1.mail.demon.net by mailstore for firstname.lastname@example.org id 899963657:10:27896:0; Thu, 09 Jul 98 05:54:17 GMT
To enable multi-drop mode you need to tell fetchmail that 'mailstore' is the name of the host which accepted the mail, and let it know the hostname part(s) of your E-mail address. The following example assumes that your hostname is xyz.demon.co.uk, and that you have also bought "mail forwarding" for the domain my-company.co.uk (in which case your MTA must also be configured to accept mail sent to email@example.com)
poll pop3.demon.co.uk proto pop3 aka mailstore no dns: localdomains xyz.demon.co.uk my-company.co.uk user xyz is *
Note that Demon may delete mail on the server which is more than 30 days old; see their POP3 page for details.
There's a different way to do multidrop. It's not necessary on Demon Internet, since fetchmail can parse Received addresses, but the person who implemented this didn't know that. It may be useful if Demon Internet ever changes mail transports.
SDPS includes a non-standard extension for retrieving the envelope of a message (*ENV), which fetchmail optionally supports if compiled with the --enable-SDPS option. If you have it, the first line of the fetchmail -V response will include the string "+SDPS".
Once you have SDPS compiled in, fetchmail in POP3 mode will automatically detect when it's talking to a Demon Internet host in multidrop mode, and use the *ENV extension to get an envelope To address.
The autodetection works by looking at the hostname in the POP3 greeting line; if you're accessing Demon Internet through a proxy it may fail. To force SDPS mode, pick "sdps" as your protocol.
fetchall'. A user reports that the 2.2
version of USA.NET's POP server reports that you must use the
fetchall' option to make sure that all of the mail is
retrieved, otherwise some may be left on the server. This is almost
certainly a server bug.
The usa.net servers (at least in their 2.2 version, June 1998)
don't handle the TOP command properly, either. Regardless of the
argument you give it, they retrieve only about 10 lines of the
message. Fetchmail normally uses TOP for message retrieval in order
to avoid marking messages seen, but `
it to use RETR instead.
Also, we're told USA.NET adds a ton of hops to your messages. You may need to raise the MaxHopCount parameter in your sendmail.cf to avoid having fetched mail rejected.
(Note: Other failure modes have been reported on usa.net's servers. They seem to be chronically flaky. We recommend finding another provider.)
Nathan Cutler reports that the the mail.geocities.com POP3 servers fail to include the first Received line of the message in the send to fetchmail. This can solve problems if your MUA interprets Received continuations as body lines and doesn't parse any of the following headers.
Workaround is to use "mda" keyword or "-mda" switch:
mda "sed -e '1s/^\t/Received: /' | formail | /usr/bin/procmail -d <user>"
Replace \t with exactly one tabulation character.
You should also consider using "fetchall" option because Geocities' servers sometimes think that the first 45 messages have already been read.
Fix: Get an email provider that doesn't suck. The pop-up ads on Geocities are lame, you should boycott them anyway.
You can't, yet. But gotmail or HotWayDaemon might be what you need.
You can't. MSN uses something that looks like POP3, except the authentication part is nonstandard. And of course they don't document it, so nobody but their Windows clients can speak it.
This is a customer lock-in tactic; we recommend boycotting MSN as the only appropriate response.
As of 5.0.8, we have support for the client side of NTLM authentication. It's possible this may enable fetchmail to talk to MSN; if so, somebody should report it so this FAQ can be corrected.
The SpryNet POP3 servers mark a message queried with TOP as
seen. This means that if your connection drops in mid-message, it
may end up invisibly stuck on your mail spool. Use the
fetchall flag to ensure that it's recovered on the
Stock fetchmail will work with a comcast.net server...but the Maillennium POP3 server comcat uses seems to have an 80K limit on the length of downloaded messages if you use POP3 TOP to retrieve. Anything larger is silently truncated. Don't mistake this for a fetchmail bug. (Reported July 2003.)
Workaround: use the fetchall option.