Excuse the hell outta me. I'm tired, I have FMS and sometimes get
things mixed up.
First: abend is a term I picked up while helping with programs for
BigBlue mainframes; it means abort/end
i.e. not the way something is supposed to end.
Second: I meant RedHat Linux, not Apache. My ISP uses Apache with
RedHat.
Third: SMTP doesn't store messages, POP3 does. And the way they are
stored *has* changed from single flatfile to index & database. If you
don't believe me, see if you can get one of the techies at my ISP to
explain it to you better.
Fourth: Unless/until you believe what I say in Third item above,
there's no sense in generating a response.
Fifth: All of that aside, regardless of how anything is stored anywhere
on the POP3 server, I'd still like the POP3.log file generated to be a
full capture, and not just a message [and message comand] log. Only
that way can problems be pinpointed.
====
On Sat, 8 Sep 2001 19:52:51 -0400 (EDT), Steve <[EMAIL PROTECTED]> wrote:
> On Sat, 8 Sep 2001, L.D. Best wrote:
>> Back to the downloads themselves. I know there is a lot quoted here,
>> after this message. It's the recurring story of abend in POP3 download
>> resulting in new download being from 1 all over again.
> What's "abend?" Deutsch evening? Do you perhaps
> mean "abort?" (abend is not in my dictionary)
>> Now it used to be that the way things worked on Apache [and many other
>> Linux] servers was this: the POP3 mail for each user was stored as a
>> flatfile and the DELE commands were never executed until after QUIT
>> because to do so would delete everything; after QUIT the DELE commands
>> were used to "edit" the flatfile.
> Apache is not a POP3 server. It is a web server.
>> However, it's been a couple of years since Apache reworked the POP3
>> stuff and it's now stored in a database with an index for each user and
>> DELE happens at the time the command is received.
> This makes no sense at all. Apache, AFAIK, has NEVER
> been associated with any POP3 server. Also, there is
> no database directly associated with either Apache,
> or ipop3d.
> True, on Linux machines, the mail files are kept
> in a single file containing many e-mails. Each file
> resides in /var/spool/mail/username. This is the
> default way SMTP stores messages.
> Apache... database... index?? Only way I can think
> of that happening would be for the ISP to be serving
> up webside e-mail. At that point, the ISP is no longer
> using POP3, which by definition, is retrieved from
> port 110 by a mail client, or manually via a
> "telnet" client.
>> At least that is how it is supposed to work.
> Huh?
> I'm not sure what assumptions you're operating under,
> or what kind of off-the-wall setup your ISP might have
> implemented, but in Linux and FreeBSD, the SMTP server
> receives the e-mail and appends it to the end of
> /var/spool/mail/username. When the user logs in on
> port 110, that mail file is parsed and transferred to
> the user in the manner consistent with the POP3
> commands with which you're well familiar.
> Alternately, the user might login to a shell account
> and retrieve/read his mail from any number of online
> mail readers, most commonly, PINE, mutt, elm, mail, et.al.
> There are normally no databases, web servers, or
> indices involved at all.
>> My ISP has four servers that handle the mail. I don't know where the
>> "user index" of the POP3 database is kept, but it is accessible by all
>> the mail servers. <snip>
> Without more detail on exactly how your ISP handles
> mail, anything else would be pure speculation.
>> Now that I've gotten a decent handle on telnet, I can do the
>> workarounds, captures that Arachne doesn't handle, and housecleaning
>> that way. But I shouldn't have to!
>> So if someone would seriously consider rewriting the "tool" that creates
>> the POP3 log, it might finally be possible to pinpoint what the real
>> problem is and where it resides.
> Switch to Linux and run fetchmail in verbose mode.
> ;-) <ducking>
> - Steve
-- Arachne V1.70;rev.3, NON-COMMERCIAL copy, http://arachne.cz/
