Gene Heskett posted on Thu, 15 Nov 2012 05:42:33 -0500 as excerpted:
> On Thursday 15 November 2012 05:06:47 Anne Wilson did opine:
>
>> The only time I see bounces is when I accidentally post with a wrong
>> address. Some lists drop those messages, so if my message doesn't
>> appear on-list after an hour or so I check which ID was attached to the
>> message.
>
> I do that too. The bounced message was correctly From: labeled when it
> left here.
That was what I was alluding to earlier when I said only you or the list
admin (checking the log) could verify that. Now that you've specifically
stated that it was sent from the correct address, my theory of some sort
of inactive timeout gets stronger.
>> > However when it became obvious that the gmail as a sending server did
>> > 2 things I don't like, 1st, the echo back to me from the server is a
>> > dup
Pan used to do that years ago with news posts (which all my list posts
are here, since I read and post thru gmane's list2news service). That
was frustrating indeed. But after the rewrite it switched to not keeping
the original (unless specifically saved as a draft), so I see it as a
news post on gmane after it's posted to the list, just as everyone else
gets it (thru gmane or direct thru the list).
The problem now of course is that if I didn't save a draft copy, I can't
simply resend, I have to recompose and send a second message. With the
length of some of my messages... So if it's long and I'm in doubt I'll
try to save a draft copy... or at least not compose any further messages
until I know it has gone thru (so the autosaved draft doesn't get
overwritten). But the shorter ones I don't worry about too much, I'll
just recompose, and sometimes I simply don't bother, because someone else
got to it or it wasn't something I had any great insight into anyway, and
I was just hoping to help with a shot or two in the dark.
>> I deal with this by setting my folders to include send as well as
>> receive mail.
>
> I have considered that, but haven't done it. I want the echo from the
> server as proof it was posted and the rest of the planet should have
> seen it.
That was what bothered me about pan's old system. I had no way of
knowing whether it got posted at all, until a reply came thru. And no
way of tracing added headers, etc, either. When the rewrite was done,
there was a bit of discussion about that, and the only keep the version
that comes back down unless the user has saved a draft idea was decided
to be better. (Pan normally saves by message-id; the version sent and
the version that comes back down have the same message-id so would be
saved to the same file. But the save as draft mechanism lets the user
choose a filename, and of course the autosave has a set filename, so
that's entirely out of the normal message handling channel.)
> FWIW, for this list, the return time can be hours, same for
> the kubuntu-users server. Both give the impression they need both more
> iron and more storage in order to keep up with the traffic.
I've noticed that too, altho of course thru gmane, there's another hop to
account for as well -- it could be the listserv delaying, or gmane,
either before forwarding to the listserv, or after getting the list-
posted message back.
But, as I used to point out, email was /designed/ as an async transfer
method. Back then, most were on dialup, and the system normally keeps
trying to deliver for I believe four days by default (but it's individual
mail server policy configurable), before giving up. So a delay of a few
minutes or a few hours is nothing to be worried about.
But it's still inconvenient; much nicer when you hit refresh groups (in
news) or fetch-mail (in mail, not waiting for the timed fetch), and it's
already posted. A lot of the time "nearly instant" is the case, which
makes the times it doesn't happen frustrating, even when they're still
well within normal operating expectations.
> And despite being retired from there for a decade and change, I was at
> the annual Thanksgiving dinner yesterday, and will have an account there
> until I fall over for the last time. I helped Jim set that up in '98 or
> '99. The iron under it has been updated 2 or 3 times, so my traffic is
> far less than .1% of its capacity these days. And of course security
> patches have been applied. The only time it was ever hacked was when it
> was running on RH-6.0 with its duff bind, in '00 or '01. Jim and I
> cleaned that mess up by rebooting, and locking that guy out, putting in
> the fixed bind, and we cleaned up his mess without ever doing another
> reboot.
That's exactly why it pays for these guys to let you keep your email
accounts, etc, around. They know you well enough to know you're not
going to be using it for spam or whatever, and maintaining that
relationship can serve as a great insurance policy, when things go
haywire. Yeah, they could call in a pro and pay them big money to fix
it, but the pro would have to either figure out the existing setup or
start from scratch, thus taking more time, while you have all that stuff
in your head and can fix it with a few hours of down time, as opposed to
a few days, even if they pay you the same to do it as they'd pay the new
pro.
Plus, if some big disaster hits (the hurricane that hit NY, for
instance), those pros will be up to their ears trying to fix thousands of
businesses, while once everyone's dug out and recovering, they can simply
call you (if you weren't riding it out there to begin with).
> I am inclined to favor the idea that the server has a little known
> timeout and that if I do not post for an extended period, its sort of
> checking to see if I'm a bot or whatever. It makes as much sense as
> anything else offered. The time between posts is because 99% of the
> problems I see go by are problems I have never encountered, so I'd
> likely be more of a hindrance.
Yeah, my theory, but it does seem one of the better ones given the
evidence.
Of course my trouble with that 99% that I've never encountered is a bit
different. In many cases while I've not personally encountered it, I
know something about the general case as I keep up with kernel news and
follow a reasonable number of lists. So I'm left with the choice of
posting something rather general that may or may not help, or not
posting. But most of the time empathy wins, and I post anyway, simply
because even if I've not had the same problem, I know from experience
that just having someone to empathize and discuss theories with can
help. Plus, often I /can/ at least point someone toward a solution, or
workaround if not a solution, where they hadn't the foggiest before.
And I see the problems and want to help as best I can, even if there's
just a small chance it'll help, and/or it'll be only a bit of help.
Sometimes I get criticized for that too, but I'll often wait a bit to see
if anyone else with a closer experience answers, and if nobody else has
answered, I figure at bare minimum, my answer lets them know that others
are at least /seeing/ the post.
But I've started actively resisting the reply impulse on kmail, because I
don't have much good to say about the new akonadified version and I
switched to something else. So I've started deliberately letting others
take the lead there, and only reply with kmail alternatives if it looks
like kmail's simply not working for them any more and there's a
reasonable chance they'd be willing to switch to something else, given
the choice and a bit of guidance as to /what/ else to switch to.
At least konqueror, while I don't use it much anymore because the devs
themselves apparently only consider it a "toy browser", I can still keep
around without it dragging in all sorts of unwanted semantic-desktop
dependencies that slow kde down even when run-time turned off, if kde's
even just built with them in the first place. Unfortunately that's just
not possible with pretty much anything kdepim related, these days.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
___________________________________________________
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
