[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-commits
Subject:    Re: kdepim/kmail
From:       George Staikos <staikos () kde ! org>
Date:       2003-04-29 16:22:05
[Download RAW message or body]


I'm not going to fragment this huge message by commenting inline. :)  However, 
yes, popping up a dialog is ideal.  I don't know if it's necessary for a 
3.1-branch bugfix though.  Of course you should leave it as such in HEAD.

For now, a way to get email to send when a specific SMTP server is unreachable 
is ideal.  My stupid ISP thinks that blocking port 25 everywhere is going to 
prevent spam.  What I did is setup a transparent proxy that sends port 25 to 
another machine out on the net and then redirects it to the intended target 
from there.  When I at another location with this same ISP (very large ISP), 
I no longer have this luxury. The problem is that I can't use a different 
SMTP server for this case.  When I write email, it just sits there and blocks 
the rest of my outgoing.  If I happen to remember and notice, I have to hunt 
through and find the one blocking sending and move it to drafts.  Then 
hopefully I remember to send it later.

The branch is really just a place for bug fixes, and the bug fix doesn't have 
to be ideal or perfectly clean, as long as it fixes the bug.  The code is 
lost for all but future bug fixes in that branch anyways.  As long as all 
mail to a given SMTP server is skipped and the next SMTP server is sent, I 
think that's an ideal solution for the branch.  If that's not possible/easy 
to do, then feel free to ignore and I'll have to wait for 3.2.0.


On Tuesday 29 April 2003 01:31, Till Adam wrote:
> >    Actually I would be happy to just bypass email that cannot be sent and
> > retry on the next send.  Doesn't that make sense?
>
> Ok, here's why I implemented it this way. As far as I can see there is no
> reliable way to tell why sending a message failed. It could be the
> transport, or something wrong with the message. If the transport fails
> (which I can't detect), all other messages for this transport will fail. I
> could then unconditionally try sending the ones with a different transport,
> but if it was just a broken message, the other messages for the same
> transport will still be blocked. There are several bug reports from people
> having sending blocked by a broken message. I think popping up a dialog
> that sending a message failed is the right thing to do, as it is an
> exceptional condition the user should be informed of, but she should still
> have the possibility of trying to continue, which is what I implemented.
> Also, imagine you have an outbox full of mails all for the same transport.
> The first one fails, because your link is down, for example. Should kmail
> really try for every single message until they have all failed, without
> asking the user if she wants to avoid that? So, considering that I assume
> the most common case to be a single transport configured, and that I cannot
> detect the reason for failure, which means I have to either potentially
> hammer a link that is down, or keep blocking like we currently do, I
> figured the way I did it is a good compromise. There is one case in which
> this is very inconvenient, I do see that. If you have 10 mails in the
> outbox using one transport, and 10 using another and the first one fails,
> you have to click continue 10 times to get to the working ones, which will
> then be delivered. How about a kind of "Continue all" button, which results
> in all further failing messages being skipped? That way only the first
> failing message would bring up the dialog. I'm not sure that is necessary
> and not rather confusing, though.
>
> If I'm out where the buses don't run with this, please tell me :).
>
> Till

-- 
George Staikos
KDE Developer				http://www.kde.org/
Staikos Computing Services Inc.		http://www.staikos.net/
[prev in list] [next in list] [prev in thread] [next in thread]