~sircmpwn/aerc

8 2

Silently failed to send an email

Details
Message ID
<C9KNSS9V8DCY.2648SXYD3QXCS@X200>
DKIM signature
pass
Download raw message
I wrote an email in aerc just now. When I went to send, I saw
"sending..." in the status bar for a moment. Then it switched to
"connected" (rather than "message sent"). Shortly after, aerc crashed
(segfault). The email was never sent.

After some time, I figured out it was because the SMTP authentication was
wong. It seems when IMAP authentication is wrong, you are informed right
away. When SMTP is wrong, you are just not told and aerc silently fails.

Can anyone else reproduce this? Is it okay if I add two tickets:

1) Alert when SMTP can't be reached (refused auth, TCP timeout, ...)

2) Save outgoing emails. This would also help if you try to send an email
   with a less-than-perfect Internet connection. That way aerc can try to
   send them in the background. AFAIK most email clients have some sort
   of "outgoing" box.
Details
Message ID
<20210227223505.fp7mphmijbwdbom4@feather.localdomain>
In-Reply-To
<C9KNSS9V8DCY.2648SXYD3QXCS@X200> (view parent)
DKIM signature
pass
Download raw message
On Sat, Feb 27, 2021 at 05:16:52PM -0500, Mark Dain wrote:
> I wrote an email in aerc just now. When I went to send, I saw
> "sending..." in the status bar for a moment. Then it switched to
> "connected" (rather than "message sent"). Shortly after, aerc crashed
> (segfault). The email was never sent.

Which version are you on?
I've fixed exactly that on the master branch in 67923707ffd826ad1d02c0a5b5ebd75ffbc71364

> After some time, I figured out it was because the SMTP authentication was
> wong. It seems when IMAP authentication is wrong, you are informed right
> away. When SMTP is wrong, you are just not told and aerc silently fails.

Same here, fixed on the master branch

> Can anyone else reproduce this? Is it okay if I add two tickets:

No need, already fixed.
We just need to release a new version.

> 2) Save outgoing emails. This would also help if you try to send an email
>    with a less-than-perfect Internet connection. That way aerc can try to
>    send them in the background. AFAIK most email clients have some sort
>    of "outgoing" box.

Now, here's where it gets a bit hairier...

*If* the sending fails you'll notice immediately, as the composer will pop back
up (with an error message).

However, if you did set "copy-to" and you loose connection right after sending
but prior to us being able to copy the message to the sent folder, you'll loose
your copy.

If your copying to sent happens server side, you're golden.

There's been some discussion going on as to how to improve that, but no satisfying
solution has been brought forth.

In case you have any ideas, I'd be happy to hear them.

Cheers,
Reto
Details
Message ID
<C9KOEKEAXLOS.1LXOWTXDU0OKF@X200>
In-Reply-To
<20210227223505.fp7mphmijbwdbom4@feather.localdomain> (view parent)
DKIM signature
pass
Download raw message
On Sat Feb 27, 2021 at 5:35 PM EST, Reto wrote:
> Which version are you on?
> I've fixed exactly that on the master branch in
> 67923707ffd826ad1d02c0a5b5ebd75ffbc71364

I recompiled just this morning, I'm at HEAD, ahead of 67923707ffd:

% aerc -v
aerc 0.5.2.r38.g8b4f2d1

% git rev-parse HEAD
8b4f2d148c8519326f306fd14ba872d7cb3101c6

> However, if you did set "copy-to" and you loose connection right after
> sending but prior to us being able to copy the message to the sent
> folder, you'll loose your copy.

Hmm, I see what you mean.

> There's been some discussion going on as to how to improve that, but no
> satisfying solution has been brought forth.

Is there a thread you can point me to? Or perhaps this discussion has
happened over something ephemeral like IRC?
Details
Message ID
<20210227231531.2bxnidfbt33av3ck@feather.localdomain>
In-Reply-To
<C9KOEKEAXLOS.1LXOWTXDU0OKF@X200> (view parent)
DKIM signature
pass
Download raw message
On Sat, Feb 27, 2021 at 05:45:19PM -0500, Mark Dain wrote:
> % aerc -v
> aerc 0.5.2.r38.g8b4f2d1

I see, but then if you have an incorrect password the composer opens up
when you try to send...

Unless you managed to crash aerc right in the 2 seconds it takes to do that,
which would be unfortunate.

> > There's been some discussion going on as to how to improve that, but no
> > satisfying solution has been brought forth.

> Is there a thread you can point me to? Or perhaps this discussion has
> happened over something ephemeral like IRC?

Well, "ephemeral" as in it survives until the logs get purged from every user
that logs it... I log it at least twice :P

And now we have it on the ML as well:

<fourstepper> command/compose/send.go , l 147 - I am thinking if possibly it wouldn't be better to not send the e-mail in case aerc fails copying it to the sent folder? Sometimes it is critical to reference e-mails and I have been bitten by this already, where the e-mail sent but I didn't have a copy and thus had a hard time reacting to phone calls and what not
<bookworm> fourstepper: the current master code sends the email and then copies it to sent, it errors out if the mail can't be sent to the recipient
<bookworm> copying it to the sent folder is done *after* the email was already sent
<fourstepper> How about just reversing the strategy
<bookworm> hence we can't abort sending as this has already happened
<bookworm> and then you end up with a copy in sent and none in your recpient's inbox?
<fourstepper> Does that sound like a bad idea?
<fourstepper> It would have to be apparent that it failed to send. Either that, or do some trickery such as copy to sent, confirm it sent correctly and if not move to postpone
<bookworm> well, it tells you as much >message sent but copying to $path failed: $reason
<bookworm> what we could do is leave the message in the temp dir, but as soon as you reboot and such the email is gone either way
<bookworm> I do agree that the current behavior is suboptimal, but I'm not sure how it should work
<bookworm> I can reopen the composer, but that's confusing and people will think that the sending failed, which it didn't, which will mean that recipients will get the mail twice
<bookworm> as people might miss the status at the bottom, especially if they are trigger happy with the keyboard as that ovrerides the status
<fourstepper> I am that person
<fourstepper> :D
<fourstepper> I am also unsure about how to handle this, but I think the way it works now creates a potentially pretty bad experience
<fourstepper> Are we able to detect if the message has been sent successfully?
<bookworm> yes
<fourstepper> How about we add a string to the email or the subject of the email if it wasnt sent properly and move it to the postponed folder, else move it to sent without modifying it?
<fourstepper> Idk if that would help, especially since when you cannot write to the sent folder you are already possibly doomed
<bookworm> bad idea (modifying the mail is a nogo) and if you can't talk to the sent folder you can't talk to "drafts" either
<fourstepper> I suppose so
<fourstepper> Hmm.. it would be nice to be able to notify the user more intrusively that sending failed I guess
<fourstepper> Because other than that I don't see much of a way out
<fourstepper> And I mean intrusive in a nice way here
<bookworm> The sending doesn't fail, if that fails you'll know immediately
<bookworm> as we re-open the composer
<bookworm> the copying to the sent folder, that one is harder to do
<fourstepper> I keep mismatching them, sorry - yeah, obviously the copying is the issue
<bookworm> I'm having issue to come up with a good solution... we can't really do anything about the fact that we already sent the mail but can't copy it to the sent folder
<bookworm> we can leave the local email somewhere on disc, but that doesn't help you much
<fourstepper> How about making sure that the sent folder is available for writing in the send action?
<bookworm> to be honest, all of that can be solved if you use the server to copy email you sent to the sent folder
<bookworm> that's racy
<bookworm> I mean even now you essentially have a race and must loose connection right after sending but prior to the copy
<bookworm> or quit aerc or whatever let to you loosing your copy
<fourstepper> I have aerc running locally and this has happened to me three times by now. I have since made aerc dump logs for each session so I know whats going on when it happens
<fourstepper> But I too agree its not ideal, mostly a not-so-great hotfix
<bookworm> which version are you on? master?
<bookworm> if not do update
<fourstepper> Yeah
<bookworm> but then what's the error?
<bookworm> do you loose connection that often?
<fourstepper> Idk, I didnt have the logs enabled
<fourstepper> Sadly.
<bookworm> ah so it only happened once and that made you paranoid?
<fourstepper> Nah, as I said it happened like three times but it wasnt as critical as recently which made me actually preserve the logs
<fourstepper> What we are discussing and https://todo.sr.ht/~sircmpwn/aerc2/266 are the two main problems I am facing the most, with the issue in the bug report presenting itself more often but being a bit less critical
<bookworm> I mean it's fairly easy to dump the content of the file somewhere locally, but it'd most probably be /tmp and then you need to be quick enough to remember to actually do something with it
<fourstepper> ^ and that's if a person notices that the issue has happened
<bookworm> yes, although the status tells you for whatever that's worth
<bookworm> we consider the email sent because it actually *is* sent
<bookworm> even though you might not have a local copy
<bookworm> fwiw I had gmail open for a few hours and the connection is still there
<fourstepper> I am not saying that's not the case for myself too. Unless I suspend the pc or something weird that I didn't log happens, aerc is running well


Cheers,
Reto
Details
Message ID
<C9KPLOBJIKFO.20ORHGZPFTBGZ@X200>
In-Reply-To
<20210227231531.2bxnidfbt33av3ck@feather.localdomain> (view parent)
DKIM signature
pass
Download raw message
On Sat Feb 27, 2021 at 6:15 PM EST, Reto wrote:
> On Sat, Feb 27, 2021 at 05:45:19PM -0500, Mark Dain wrote:
> > % aerc -v
> > aerc 0.5.2.r38.g8b4f2d1
>
> I see, but then if you have an incorrect password the composer opens up
> when you try to send...

Yeah, I didn't get an error, but I have a hunch as to why.

> Unless you managed to crash aerc right in the 2 seconds it takes to do
> that, which would be unfortunate.

It was a good minute or so until aerc crashed. It was almost like it
tried to send, thought it was successful and so returned to the inbox.
Then later, some go routine timed out and crashed.

I'll try to copy the stack trace next time, it's just difficult to format
it well when it spews out its guts all over the terminal

> > > There's been some discussion going on as to how to improve that, but no
> > > satisfying solution has been brought forth.
>
> > Is there a thread you can point me to? Or perhaps this discussion has
> > happened over something ephemeral like IRC?
>
> Well, "ephemeral" as in it survives until the logs get purged from every
> user that logs it... I log it at least twice :P
>
> And now we have it on the ML as well:

Thanks, I'll have a read and will let you know if I have any ideas.
Details
Message ID
<20210227235127.6lvzqxqra4vyp2jv@feather.localdomain>
In-Reply-To
<C9KPLOBJIKFO.20ORHGZPFTBGZ@X200> (view parent)
DKIM signature
pass
Download raw message
On Sat, Feb 27, 2021 at 06:41:37PM -0500, Mark Dain wrote:
> Yeah, I didn't get an error, but I have a hunch as to why.

Care to enlighten me?

> It was a good minute or so until aerc crashed. It was almost like it
> tried to send, thought it was successful and so returned to the inbox.
> Then later, some go routine timed out and crashed.

We only think we are successful if the server indicates that, how did you not
get an error with an invalid password?

> I'll try to copy the stack trace next time, it's just difficult to format
> it well when it spews out its guts all over the terminal

aerc 2>/tmp/aerc.log would alleviate that, that's what I do.
Details
Message ID
<C9KPYM4OL6U9.15X54A8G0O6QJ@X200>
In-Reply-To
<C9KPLOBJIKFO.20ORHGZPFTBGZ@X200> (view parent)
DKIM signature
pass
Download raw message
On Sat Feb 27, 2021 at 6:41 PM EST, Mark Dain wrote:
> On Sat Feb 27, 2021 at 6:15 PM EST, Reto wrote:
> > On Sat, Feb 27, 2021 at 05:45:19PM -0500, Mark Dain wrote:
> > > % aerc -v
> > > aerc 0.5.2.r38.g8b4f2d1
> >
> > I see, but then if you have an incorrect password the composer opens up
> > when you try to send...
>
> Yeah, I didn't get an error, but I have a hunch as to why.

If I just change the password, I am brought back to the compose window
with bad auth error! Good to know that works.

However, I had the wrong domain. I think the wizard put my SMTP server as
something like "smtp.markdain.net". If the domain is incorrect, you'll
get a crash every time.

I have a wildcard DNS record, so there's actually an IP address there if
you resolve that subdomain. Perhaps that's why it took so long to crash.

Anyway here is the log if it's helpful:

------------------------------------------------------------------------

Sending..panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x68 pc=0x8df6e9]

goroutine 37 [running]:
github.com/emersion/go-smtp.(*Client).hello()
    /home/ancarda/go/pkg/mod/github.com/emersion/go-smtp@v0.12.1/client.go:114 +0x29

github.com/emersion/go-smtp.(*Client).Auth()
    /home/ancarda/go/pkg/mod/github.com/emersion/go-smtp@v0.12.1/client.go:263 +0x45

git.sr.ht/~sircmpwn/aerc/commands/compose.newSmtpSender()
    /home/ancarda/src/git.sr.ht/~sircmpwn/aerc/commands/compose/send.go:329 +0x4f4

git.sr.ht/~sircmpwn/aerc/commands/compose.Send.Execute.func1()
    /home/ancarda/src/git.sr.ht/~sircmpwn/aerc/commands/compose/send.go:108 +0x98

created by git.sr.ht/~sircmpwn/aerc/commands/compose.Send.Execute
    /home/ancarda/src/git.sr.ht/~sircmpwn/aerc/commands/compose/send.go:102 +0x6ac
Details
Message ID
<20210228010814.pucp2oavg46l2o34@feather.localdomain>
In-Reply-To
<C9KPYM4OL6U9.15X54A8G0O6QJ@X200> (view parent)
DKIM signature
pass
Download raw message
On Sat, Feb 27, 2021 at 06:58:31PM -0500, Mark Dain wrote:
> However, I had the wrong domain. I think the wizard put my SMTP server as
> something like "smtp.markdain.net". If the domain is incorrect, you'll
> get a crash every time.

Debugging with a lag time of 3min per iteration, fun...

Anyhow:

commit 8cd2485170e97867321fac2f26ba876f377d5d8e (HEAD -> master, origin/master, origin/HEAD, fork/master)
  Author: Reto Brunner <reto@labrat.space>
  Date:   Sun Feb 28 02:04:58 2021 +0100

      send: fix missing error return

  diff --git a/commands/compose/send.go b/commands/compose/send.go
  index f61478f..849182d 100644
  --- a/commands/compose/send.go
  +++ b/commands/compose/send.go
  @@ -320,6 +320,10 @@ func newSmtpSender(ctx sendCtx) (io.WriteCloser, error) {
                  return nil, fmt.Errorf("not an smtp protocol %s", ctx.scheme)
          }

  +       if err != nil {
  +               return nil, errors.Wrap(err, "Connection failed")
  +       }
  +
          saslclient, err := newSaslClient(ctx.auth, ctx.uri)
          if err != nil {
                  conn.Close()


Mea culpa, that bug is on me.

Thanks for reporting (and the patience)

Cheers,
Reto
Details
Message ID
<C9KRN6ZLBMUV.1TKAJCK1AZ478@X200>
In-Reply-To
<20210228010814.pucp2oavg46l2o34@feather.localdomain> (view parent)
DKIM signature
pass
Download raw message
On Sat Feb 27, 2021 at 8:08 PM EST, Reto wrote:
> + if err != nil {
> + return nil, errors.Wrap(err, "Connection failed")
> + }

Just tried this, it works great! Thank you!

> Thanks for reporting (and the patience)

No problem, I'm glad I could help
Reply to thread Export thread (mbox)