Once the message sending failed it's impossible to retry. For example,
the server has an expired certificate, so every time I restart Claws I
have to accept it on first message send. If I forget about it, the
connection would time out, so pressing Accept does nothing but produces
'Failed to send message' messagebox. If I click Send button once more,
it just fails immediately without even trying to connect, and nothing
can be seen in the logs. However, if I edit the message and send it
again, it works.

It seems this bug has been introduced quite recently, as on the other
laptop I have an older version, and I've never experienced this bug.

severity 701093 minor
tags 701093 moreinfo unreproducible
thanks

  This looks like a corner case, as the usual is to answer the dialog
when shown.

  There's some changes which could fix this in current upstream CVS.

  Unfortunately the CVS packages autobuilder (http://hydra.debian.net)
  is currently stopped, so you can try to build CVS yourself, or wait a
  bit for the autobuilder if you want to test with a packaged version
  of latest CVS.

  regards,

Hello.

Sorry, I disagree. It's reproducible always. Also, it's not minor bug,
as it requires restart to fix it. It'd like to retag it.

Well, it's not. I can't answer a dialog I don't see, and usually right
after sending the message I switch away to a different desktop/screen
tag, and the dialog apparently doesn't have 'urgent' flag set.

Hello.

By the way, I've just reproduced the bug with cvs61 version. Can't
build directly from CVS currently, so no info about latest code.

  Hi Andrew,

  Not on other systems. That's what unreproducible means: other people
don't see the same. Nobody says you don't have the problem or cannot
reproduce it.

  You said simply re-editing the message suffices for it to work. That's
a very simple workaround, not a "restart". It only happens on specific
server situations (expired certificates) and very specific user behaviour
(the user ignores/forgets to answer the dialog). All of this, IMHO, qualifies
it more as a minor bug than a normal bug.

  Dialog urgency hint is a different problem, unrelated to the sending
failure when the connection times out. Can you please file a different bug
for that?

  regards,

Hello.

I know what unreproducible means. Probably, you didn't try hard enough
:) When I said it's reproducible here always, I meant if you try to
simulate the situation closer to mine you *will* get this.
which indicates there's certainly a bug. Also, I guess it may be
reproduced without expired certificates; I will try that later. Also,
a checkbox “remember my choice” would be useful.

Well this is indeed a minor problem, I wouldn't mind that if that
didn't bring this bug to the surface.

Hello.

Just reproduced it with unreachable SMTP server. Raising the severity back.

  Could you detail the steps you did to reproduce that?

  regards,

Hello.

* Make sure the server is unreachable, for example by this: ip route
add smtp-server dev lo
* Compose new message and try to send it.
* Wait for the timeout.
* Observe the error message.
* Try re-sending it.
* It fails.

Well, now I've copied the exact message, which makes things more
clear: “Some errors occurred while sending queued messages: Couldn't
determine sending informations. Maybe the email hasn't been generated
by Claws Mail.” Somehow I missed the point of this last time. I'd be
rather than happy if Claws could re-generate that information on the
fly. Or not rely on its existence at all.

P. S. Well, actually, Send later doesn't work as well. Something's
horribly broken.

  Hi,

  So you're trying to re-send without making the server reachable again
and expect it to succeed? Is this a joke? :-P

  Yep, your test :)

  regards,

Hello,

Erm, it seems like you're joking. Of course I meant it's reachable
again, but, well, either I have it reachable or not, Claws *must* try
to deliver it, and it doesn't, and the network log shows, and the
message I get confirms that.

Do you really want me to dig into the code? If I was you I'd not dare
to let me do that :D

Hello,

Okay, it seems like I understand what's going on. I use IMAP mailbox,
and the server filters out all those special non-standard Claws mail
headers. I see no real reason to use them at all, as this information
can be found in standard RFC headers which already exist in the
message. Please don't rely on them.

  Hi,

  No, no joke. Just wanted the detailed steps. There's no step saying
the server is made reachable again.

  There's no network log attached to this mail. Can't say much more.

  Only if you're sending a patch with the fix after digging.
  Otherwise don't even bother, you probably wouldn't understand it :)

  BTW, you should test with CVS code first, as suggested in my first answer.

  thanks in advance,

Hello.

Well, it's empty.

Couldn't you please point me to the mailing list message regarding the
commit? I'd like to look at the patch itself (I can't test it
currently).

severity 701093 wishlist
tags 701093 = wontfix
thanks

  The standard headers doesn't have the details saved in the special
header. Have you seen them?

  Anyway the server must not remove headers sent by the client unless
they have invalid data (8-bit data) which is not the case. Which IMAP
server is that which removes client data without warning or error?

  There's no place in the RFCs (3501/2600) that allows that kind of
server behaviour, so it's either a bug or a stupid feature of that server.
But clearly not a claws-mail bug.

  Since you have changed the title I guess you don't want to close this
report, which has become a feature request in fact, so tagging accordingly.

  regards,

Hello.
and To:? That should be perfectly enough to send a message. There's
absolutely no reason to refuse sending a message which doesn't have
Claws special headers.

This is what I have and I have no option to change the server
behaviour. No other mail client is affected by this behaviour, so this
is a fault of Claws Mail.

I'd like it to be fixed, however. When the message is still in Drafts,
it doesn't have any special headers. There's no reason to refuse to
send it, as I said before.

  Hi,

  There's account configurations for things like where to put account's
sent messages or if messages have to be digitally signed, and more. That
information cannot be extracted from To or From.

  That info is required for claws-mail to work properly, and there's no
reason for the server to remove it.

  No, that you can't change the server which is violating the IMAP standards
doesn't make it a client problem :) The other servers out there had never
such problem.

  In any case, you can put your drafts in a local folder instead of server's
and the problem should be fixed. Of course, this has drawbacks if you use
different computers.

  Yes, there is, as explained above. If the local folder drafts workaround
doesn't work for you the only thing I can recommend is to try other mail
clients in Debian and see if they work better with that ugly server.

  regards,

Hello.

I have just one account here. There's no problem to have some
heuristic or user-configurable rules.

Why don't other clients do that?

I'm not speaking about drafts, but the outbound queue. There's no
reason to keep in on the server at all, by the way.

I don't want other mail clients! This can be worked around quite
easily, at least for simple configurations.

Also, what about 'remember my choice for this certificate' checkbox?
And urgency hint?

  Hi,

  I have dozens. It has to work in all cases, not in yours only.

  Most of the clients out there add or allow adding extra headers to
messages, from X-Face images, to any other imaginable stuff. Claws Mail just
uses it also to save more interesting information. And is perfectly valid.
Other clients may use a database or whatever they see appropriate. They
may be slower though.

  You can also move it to a local folder. It's on the server because people
usually wants it there, but you can configure your imap account to use a
local queue.

  Fine, I'll wait for your patch then.

  BTW, upstream developers are famous for not workarounding things for
non-compliant servers, but you may be lucky if the patch is good enough.

  You can disable certificate checks if you want. See hidden preferences:
http://www.claws-mail.org/manual/en/claws-mail-manual.html#adv_hidden.

  Feature request, file the corresponding wishlist bug.
  I'll forward it to upstream.

  regards,

  Hi,
[...]

  Just going back to this (I've been somewhat busy...)

  You can put the queue in a local folder too, there's no need to put
it on the server, see account preferences, advanced tab. That should
prevent the server from changing the mail.

  regards,