Random Eudora questions and comments

At 12:01 -0700 06/28/2004, Bob Williams wrought:

>- Along with In, Out, and Trash, Eudora keeps the TOC of any open
>mailbox in memory.

I asked Steve about memory usage a few months ago:

At 10:47 -0800 01/15/2004, Steve Dorner has written:
>Does Eudora still keep IN, OUT, and TRASH in memory?

Not exactly.

Under OS 9, it does request a partition size big enough to handle having
the toc's for all three of those mailboxes in memory, because it's a good
bet that they will need to be in memory at the same time.

But that's just the toc's, not the mailboxes themselves.

The toc's for any open mailboxes are always in memory, including
mailboxes belonging to any open messages.

Chris

<x-eudora-setting:9603> # of days after which to consider mailboxes not to have unread mail.

It says the value must be between 0 and 30 days.

Yes, the limitation is just a sanity check to protect users. Eudora won't care, unless you make it so big that the resulting date overflows a long value, which would only happen if you set it to 30 years or so.  (2036 is the year that unix time with four-byte longs goes belly up, I think.)

I use Eudora (5.2.1, light) from my laptop on a number of different locations and I notice significant differences in sluggishness during mail checks. This sluggishness seems to have become more pronounced since the firewall protecting the POP3 server was reinforced. However, Eudora's slowest performance occurs when my laptop is behind the firewall too.

The other quirk that people report, Eudora waiting seconds before filling in windows or dropping menus occurs occasionally but does not seem to be correlated with specific locations.

Minus van Baalen

You still easily do miss new messages if you sort the mailbox by Date, which many people do. Then the new message with the old date ends up somewhere at the top of the mailbox, which is mostly out of view.

For many years, I had Eudora set to list mailbox windows sorted by date. This had the effect described above.

Then one day I discovered by accident that you can unselect all the column headings. This means that the messages are not sorted by anything, and new mail gets added at the bottom, irrespective of its date.

Now I have all my mailboxes set this way to catch those odd-date messages. If I feel the need to tidy it up a bit, I just click once on the Date column heading to sort them all, then again to unselect it.

I am continually amazed at the features Eudora has that are just so obvious once you discover them.

David

From: Chris Pepper <pepperreppep.com>
At 12:28 PM -0700 2004/06/24, Sander Tekelenburg wrote:
>>not marking a mailbox as contaiining unread mail when the message in
question contains a date way back in the past

>You're describing a feature.

No, it's a bug.

Mailbox named "Bother" has 85 messages in it. A new message is
delivered to Bother, but because my brother's battery on his powerbook
is dead, it has a date of 1904.

Guess what? No notification of a new email.

_THAT_ is a bug. period.

>I don't know if 0 means always/never, but 3650 days should do the trick).
>
><x-eudora-setting:9603>

Maximum value is 30.

--
gkreme at gmail or kreme at kreme or syth at mac

At 10:43 -0700 on 6/30/04, Google Kreme indited:
>Mailbox named "Bother" has 85 messages in it. A new message is
>delivered to Bother, but because my brother's battery on his powerbook
>is dead, it has a date of 1904.
>
>Guess what? No notification of a new email.
>
>_THAT_ is a bug. period.

Whether Eudora's behavior in this situation could
be considered a bug in technical terms is
debatable, but regardless, the main culprit here
is your brother. When the date on a computer is
off by more than 100 years, all sorts of crazy
things begin to happen and go wrong, many of them
not noticeable except upon close inspection. In
this case, mis-categorization of a mail message
is the least of the problems.

Operating systems rely on accurate, or at least
semi-accurate, clocks in many ways, and IMHO,
it's okay for applications to in turn assume that
the OS is feeding accurate times. I believe Mac
OS even warns you at some point if your clock is
set to a strange time, but ultimately, making
sure the time is right is under user control.

Now, I do think Eudora should track both received
(local workstation) and sent (sender's
workstation) times, and maybe even
cross-reference them with the times reported by
the mail server, but that still doesn't mean that
the current behavior is a bug. It just means
there's room for enhancement.

> >I don't know if 0 means always/never, but 3650 days should do the trick).
>>
>><x-eudora-setting:9603>
>
>Maximum value is 30.

As reported by another Christopher Stone, who
asked Steve Dorner, that 30 days bit is simply
there as a weak attempt to keep the user from
entering something too outrageous. In truth, you
can set it to a very large value. To wit:

At 15:00 -0700 06/28/2004, Steve Dorner has written:
>Yes, the limitation is just a sanity check to
>protect users. Eudora won't care, unless you
>make it so big that the resulting date overflows
>a long value, which would only happen if you set
>it to 30 years or so.Ý (2036 is the year that
>unix time with four-byte longs goes belly up, I
>think.)

Granted, that doesn't enable you to cover the
1904 problem, but again, that's a user issue.

Regards,
Bob
--
Robert E. Williams, Jr.
TriVectus, LC
bobtrivectus.com
www.trivectus.com

At 07:05 -0700 UTC, on 2004/07/01, Bob Williams wrote:

> At 10:43 -0700 on 6/30/04, Google Kreme indited:
>>Mailbox named "Bother" has 85 messages in it. A new message is
>>delivered to Bother, but because my brother's battery on his powerbook
>>is dead, it has a date of 1904.
>>
>>Guess what? No notification of a new email.
>>
>>_THAT_ is a bug. period.
>
> Whether Eudora's behavior in this situation could
> be considered a bug in technical terms is
> debatable, but regardless, the main culprit here
> is your brother.

Agreed. But that's no reason for the recipient to have to suffer that. A good
user-agent gives the user as much control as possible, not the author of the
content. Otherwise Eudora would not offer to not load in-line remote images,
to ignore the author's fonts, sizes and colours in email, etc.

Exactly because Eudora does pretty well in this respect (giving the user
control) a 'feature' like this stands out negatively.

(Anyway, it's hardly a *major* issue of course :))

--
Sander Tekelenburg, <http://www.euronet.nl/~tekelenb/>

On Thu, 1 Jul 2004 07:05:41 -0700, Bob Williams <bobtrivectus.com> wrote:
> At 10:43 -0700 on 6/30/04, Google Kreme indited:
> >Mailbox named "Bother" has 85 messages in it. A new message is
> >delivered to Bother, but because my brother's battery on his powerbook
> >is dead, it has a date of 1904.
> >
> >Guess what? No notification of a new email.
> >
> >_THAT_ is a bug. period.
>
> Whether Eudora's behavior in this situation could
> be considered a bug in technical terms is
> debatable,

No it's not.

New mail arrived, Eudora ignored that it was new. Bug.

> but regardless, the main culprit here
> is your brother. When the date on a computer is
> off by more than 100 years

Fine, his clock is set back to 2003 because he's using some demo
expiring PC app. It doesn't matter, the fact is:

New mail arrived, Eudora ignored that it was new. Bug.

> this case, mis-categorization of a mail message
> is the least of the problems.

Not really. I don't care if his clock is off. It impacts me in no
way at all. Only Eudora does cares. In fact, in my setup (I don't
use Eudora), procmail filters the message into the correct date folder
regardless of the Date stamp because I use Received: headers to
determine the date and time of a message. Which is exactly what
Eudora should do instead of relying on a user-provided Date: header
that can be anything at all.

It's a bug. You can dress it up in a top hat and tails and it's STILL a bug.

> Granted, that doesn't enable you to cover the
> 1904 problem, but again, that's a user issue.

No, it's not a user issue. My mail system should not be hobbled by
someone else's wrong date. Eudora has access to the correct date info
in the headers and chooses to ignore it. I first reported this well
over 10 years ago, and even told them how to fix it (use the Date/time
stamp from the top Received header for messages more than a week out
of date, though I would say 24 hours out of date now since the email
system is a lot more robust than it was).

--
gkreme at gmail or kreme at kreme or syth at mac

[OK, let's wind this particular incredibly specific discussion down. -Adam]

At 18:52 -0600 on 7/1/04, Google Kreme indited:
> > Whether Eudora's behavior in this situation could
>> be considered a bug in technical terms is
>> debatable,
>
>No it's not.
>
>New mail arrived, Eudora ignored that it was new. Bug.

When it comes to the date, computers are fallible because they rely
on external sources. When those sources are wrong, the software will
fail. In this case, Eudora is looking at the Date: header to
determine how old the message is, and includes an expiration
mechanism based on the age - calculated from that date. If it's
working with bad data, that's not Eudora's fault. It's still doing
exactly what it was programmed to do. A bug, by definition, is where
the software does something unexpected. That's not happening in this
case; rather the data going in is bad, and it's difficult to reliably
validate that data. It's like the old programming saying goes:
garbage in, garbage out, or GIGO.

You *almost* could argue that it's a bug in the specification. But in
the end, I would say it's not, because at the time that design
decision was made, it was reasonable to assume that the sender would
have at least a semi-accurate clock. Things have changed now, and
although Eudora's ways could be improved, I wouldn't agree that it's
current behavior is a bug.

>Fine, his clock is set back to 2003 because he's using some demo
>expiring PC app. It doesn't matter, the fact is:
>
>New mail arrived, Eudora ignored that it was new. Bug.

Eudora didn't ignore it at all, though. It processed it exactly as it
was designed to process it - no surprises, no bugs. The problem is
that nowadays, Eudora's method is less-than-optimal. What you're
asking for is implementation of a good feature/enhancement
suggestion, not a bug fix.

> > this case, mis-categorization of a mail message
>> is the least of the problems.
>
>Not really. I don't care if his clock is off. It impacts me in no
>way at all. Only Eudora does cares. In fact, in my setup (I don't
>use Eudora), procmail filters the message into the correct date folder
>regardless of the Date stamp because I use Received: headers to
>determine the date and time of a message. Which is exactly what
>Eudora should do instead of relying on a user-provided Date: header
>that can be anything at all.

Unfortunately, the Received: headers are no more guaranteed to be
accurate than the Date: header. Yes, they're somewhat more likely to
be accurate more often, but there's no guarantee. As more and more
mail servers are being run by company IT folks who really don't know
what they're doing, there's an increasing chance of those machines
also having bad dates. So what you're asking for is really just a
small improvement and not a true solution. Perhaps the next major
mail protocol that replaces SMPT to handle spam will also incorporate
a mechanism of including guaranteed accurate timestamps. Until then,
software can only rely on what's fed in, and make cross-references in
an attempt to catch wildly bad data.

All that said, I, again, agree that Eudora needs improvement now, and
looking at the Received: headers is a good place to start. Just don't
count on that being the end of this problem. It's merely a patch,
nothing more and nothing less.

Regards,
Bob
--
Robert E. Williams, Jr.
TriVectus, LC
bobtrivectus.com
www.trivectus.com

At 07:05 -0700 07/01/2004, Bob Williams wrought:

>Granted, that doesn't enable you to cover the 1904 problem, but again,
>that's a user issue.

I'm not certain if this will affect the notification issue or not, but it
might.

<x-eudora-setting:11307> File dates older than this will not be believed
                          default is Jan 1, 1980.

Chris

>New mail arrived, Eudora ignored that it was new. Bug.

I think everyone, including the makers of Eudora, has missed an
important point.

Eudora does not ignore the arrival of new mail. When badly-dated
messages arrive, Eudora posts a new-mail notification to attract your
attention (unless you have elected to turn all notifications off),
the same as for any other mail. But the underlined-mailbox indicator
doesn't indicate new mail; it only indicates *unread* mail, which is
not the same thing.

New-mail notifications are global and ephemeral: they only tell you
that there is some newly-arrived mail somewhere in your mailboxes,
and the notification ends as soon as you touch Eudora. There are no
persistent indicators for "new mail" as opposed to "mail of recent
date" or "unread mail." I wish there were. I'd like a mark on a
mailbox that means "contains mail that has arrived since the last
time I paid attention to this mailbox."

--
Rick Holzgrafe
rickkagi.com
http://www.semicolon.com

On 7/2/2004 9:32, "Bob Williams" <bobtrivectus.com> wrote:

> You *almost* could argue that it's a bug in the specification. But in
> the end, I would say it's not, because at the time that design
> decision was made, it was reasonable to assume that the sender would
> have at least a semi-accurate clock. Things have changed now, and
> although Eudora's ways could be improved, I wouldn't agree that it's
> current behavior is a bug.

I see two themes repeated in many contexts, not just computers.

One of them paraphrases to
   I wouldn't have designed it that way, so it's designed wrong.

The other is
   I told them I didn't like this and they didn't change it, therefore they
ignored what I told them.

Neither conclusion follows from its premise as given above.

  --John

At 9:32 AM -0700 7/2/04, Bob Williams wrote:
>was programmed to do. A bug, by definition, is where the software
>does something unexpected. That's not happening in this case; rather
>the data going in is bad, and it's difficult to reliably validate
>that data.

I agree that the case of a bad Date: header was probably unexpected.
But it's not hard to record the date the message was received.
Eudora keeps metadata about the mailbox in which it could remember
the date received. (That's where the unread flag itself is stored.)
I think it's a bug because the whole point is to mark mailboxes with
unread mail and Eudora isn't doing that.

An even simpler solution is to not look at the Date: at all.
Instead, make a distinction between a message that's unread because
it has never been opened and one that's unread because the user
marked it unread. Then, only highlight mailboxes with messages that
have never been opened. If I have a 6-month old message that I
haven't ever opened, I probably would still like to see that mailbox
highlighted.

>Unfortunately, the Received: headers are no more guaranteed to be
>accurate than the Date: header. Yes, they're somewhat

Nothing is guaranteed, but they are much, much more likely to be
correct since a mail server is more likely to be professionally
maintained than an individual's computer. But the Received: headers
don't have to be used unless the mailbox metadata containing the
actual received time is lost.

--
Larry Rosenstein
lsralum.mit.edu

At 1:45 PM -0700 2004/07/02, Rick Holzgrafe wrote:
>>New mail arrived, Eudora ignored that it was new. Bug.
>
>I think everyone, including the makers of Eudora, has missed an
>important point.
>
>Eudora does not ignore the arrival of new mail. When badly-dated
>messages arrive, Eudora posts a new-mail notification to attract
>your attention (unless you have elected to turn all notifications
>off), the same as for any other mail. But the underlined-mailbox
>indicator doesn't indicate new mail; it only indicates *unread*
>mail, which is not the same thing.
>
>New-mail notifications are global and ephemeral: they only tell you
>that there is some newly-arrived mail somewhere in your mailboxes,
>and the notification ends as soon as you touch Eudora. There are no
>persistent indicators for "new mail" as opposed to "mail of recent
>date" or "unread mail." I wish there were. I'd like a mark on a
>mailbox that means "contains mail that has arrived since the last
>time I paid attention to this mailbox."

        In the default configuration, Eudora does this by bringing
the new-mail boxes to the front, except for a frontmost composition
window, if present. This means that I keep a lot of windows open, but
the open mailbox state is pretty persistent (not robust enough for
me, but it works for months to years at a time, until disturbed by an
accidental Command-Option-W, or save problem at Quit time, or
settings file corruption).

        You could also get a Filter Report, which is *too*
non-ephemeral for me.

                                                Chris
--
Chris Pepper: <http://www.reppep.com/~pepper/>
Rockefeller University: <http://www.rockefeller.edu/>

At 18:09 -0700 07/04/2004, Chris Pepper wrought:

> You could also get a Filter Report, which is *too* non-ephemeral
>for me.

The 'Filter Report' is cleared every time it's window is closed. I
started using it all the time a year or so ago for a couple of reasons:

* A double-check for received mail (I also have mailboxes set to open
when new mail is received).

* A check for manually filtered messages. Every so often a message a
manually filter gets caught by a filter I'm not expecting. The FR gives
me an easy visual check for this.

* I use a bunch of manual filters to winnow my Junk mailbox. Items moved
to the Trash are not registered in the FR window, but moves to any other
mailbox *are*. Again I have a fast visual check for unexpected behavior.

I have a script to close non-essential windows bound to Control-Shift-C
with QuicKeys:

  -- Created : 2003/05/25 00:15
  -- Modified : 2004/06/28 17:30
  -- Author : Christopher Carsten Stone <junksievecox.net>
  -- Description : Eudora: close non-essential windows.
  -- Dependencies : None

  -->> ===={€ Main }==========================================================

  tell application "Eudora"
    try
      if exists of window "Filter Report" then
        close window "Filter Report"
      end if
     
      if exists of window "Address Book" then
        close window "Address Book"
      end if
     
      if exists of window "Filters" then
        close window "Filters"
      end if
     
      if exists of window "Find" then
        close window "Find"
      end if
     
      if exists of window "Mailboxes" then
        close window "Mailboxes"
      end if
     
      if exists of window "Task Progress" then
        close window "Filter Report"
      end if
     
    on error errMsg number errNum from errFrom partial result errResult to errTo
      set msg to errMsg & return & return & "Number: " & errNum
      beep
      display dialog msg with icon 0 giving up after 60
    end try
  end tell

Chris

A number of people reported inexplicable delays while using Eudora. I've seen the same thing under circumstances of tenuous (or slow) network circumstances, but never when at work and connected to a 100BaseT network (same PowerBook in all cases). It appears that Eudora does some kind of network checking/verifying/validating while idle (or a network is first detected).

I'm not sure what it is doing when checking a network, but I very much wish it would mind its own business until such time it is either told to go send and/or get mail, or it is a scheduled ("every N minutes") time. Mine is configured not do do so when on battery, but it still seems to want to poke around the network when idle.

Does anyone have any insight to add to this? Anyone know how to turn it off?

- Steve

On 7/30/2004 17:50, "Steve Davidson" <sd-spamcomcast.net> wrote:

> A number of people reported inexplicable delays while using Eudora. I've seen
> the same thing under circumstances of tenuous (or slow) network circumstances,
> but never when at work and connected to a 100BaseT network (same PowerBook in
> all cases). It appears that Eudora does some kind of network
> checking/verifying/validating while idle (or a network is first detected).
>
> I'm not sure what it is doing when checking a network, but I very much wish it
> would mind its own business until such time it is either told to go send
> and/or get mail, or it is a scheduled ("every N minutes") time. Mine is
> configured not do do so when on battery, but it still seems to want to poke
> around the network when idle.
>
> Does anyone have any insight to add to this? Anyone know how to turn it off?

You don't say, so I'll ask: which mode is Eudora in? Sponsored mode would
do something like what you describe.

IMAP server? Mess about with the connection-related settings in the IMAP
settings pane from Esoteric Settings.

  --John

><<a href="/webx?13@@.3c4d5c72/32">Steve Davidson, "Random Eudora questions and comments" #33, 30 Jul 2004 5:50 pm</a>>Message #33: Re:
>Random Eudora questions and comments
>Posted by Steve Davidson on 05:50pm Jul 30, 2004
>
>A number of people reported inexplicable delays while using Eudora.
>I've seen the same thing under circumstances of tenuous (or slow)
>network circumstances, but never when at work and connected to a
>100BaseT network (same PowerBook in all cases). It appears that
>Eudora does some kind of network checking/verifying/validating while
>idle (or a network is first detected).
>
>I'm not sure what it is doing when checking a network, but I very
>much wish it would mind its own business until such time it is
>either told to go send and/or get mail, or it is a scheduled ("every
>N minutes") time. Mine is configured not do do so when on battery,
>but it still seems to want to poke around the network when idle.
>
>Does anyone have any insight to add to this? Anyone know how to turn it off?
>

Here are some excerpts from an email discussion a while back,
including a response from Steve Dorner:

At 5:44 PM -0400 2003/09/29, Joel Smith wrote:

>I have been reporting this as a bug for about a year now. The issue
>is that Eudora is doing a DNS lookup on the dominant user POP
>account at some point. I have proven this by doing a tcpdump and
>watching the traffic.
>
>This is a big issue for me, as I use an ISDN connection with dial on
>demand. If I have Eudora open, then it will do a DNS lookup every so
>often. I set up a local DNS server to try and catch these, and save
>a connection. However, the problem is that my ISP has the DNS
>entries for the POP3 server set to timeout after 5 minutes. This
>means that after 5 minutes, my local DNS server will have to make an
>external lookup to update the information (involving an ISDN call).
>
>As I said, I reported this to Eudora, but their response has been
>that there is no code which does DNS lookups. However, when I have
>Eudora running, DNS lookups are done. When I quit Eudora, the
>lookups stop. The lookups coincide with the freeze in typing an
>email in Eudora.

At 6:37 pm -0700 29/9/03, Steve Dorner wrote:
>Apple recommends that, in order to avoid unnecessary dialling, you
>use their SCCheckForNetworkReachabilityByHostname call. The first
>thing this call does is a synchronous DNS lookup for the hostname
>(bright, Apple). :-( This is very unsatisfactory, but nothing else
>fits the purpose.
>
><x-eudora-setting:154=y> will stop the behavior, which is really
>only useful if you do dial-on-demand directly from your Mac.

At 11:36 am +0100 30/9/03, Joel Smith wrote:
>I made the change, with no apparent difference. If I put the IP
>address rather than the name in, Eudora doesn't do any spurious
>lookups.
>
>Cheers,
>
>Joel

So, no solution other than a workaround. Soon after this, I set up a
broadband network, so the problem went away anyway.

Cheers,

Joel
--

Joel Smith
Dales IT Ltd

On Sun, 1 Aug 2004 06:30:01 -0700, Joel Smith <joeldalesit.com> wrote:
> >This is a big issue for me, as I use an ISDN connection with dial on
> >demand. If I have Eudora open, then it will do a DNS lookup every so
> >often. I set up a local DNS server to try and catch these, and save
> >a connection. However, the problem is that my ISP has the DNS
> >entries for the POP3 server set to timeout after 5 minutes. This
> >means that after 5 minutes, my local DNS server will have to make an
> >external lookup to update the information (involving an ISDN call).

If the IP of the mailserver is not changing then set the IP in
/etc/hosts which will prevent that hostname from ever being looked up
by DNS.

--
gkreme at gmail or kreme at kreme or syth at mac
 :: Don't get saucy with me, Bernaise ::

jwblist wrote:

You don't say, so I'll ask: which mode is Eudora in? Sponsored mode would do something like what you describe.

IMAP server? Mess about with the connection-related settings in the IMAP settings pane from Esoteric Settings.

Appreciate the attempt, but no luck. It is paid mode, and I only use POP3 (never IMAP). Thanks.