[Desktop-packages] [Bug 2020621] [NEW] "wpctl status" causes line wrap with big PID values

2023-05-23 Thread Bernhard Riegler
Public bug reported:

/usr/bin/wpctl is in package "wireplumber"
cat /proc/sys/kernel/pid_max 
4194304
Ubuntu 22.04LTS has PID value up to 4Mi (7 digit decimal)
on a std terminal with 80 colomns it wraps lines if more then 5 digits for PID 
in my case.

please fix the output of "wpctl status" for 7 digit PID value without line wrap.
I see 8 SPACE characters at begin_of_line which can be reduced.

 └─ Clients:
31. pipewire[0.3.68, bernie@prod, pid:1434]
33. WirePlumber [0.3.68, bernie@prod, pid:1432]
34. WirePlumber [export][0.3.68, bernie@prod, pid:1432]
46. GNOME Shell Volume Control  [0.3.68, bernie@prod, pid:3162]
47. GNOME Volume Control Media Keys [0.3.68, bernie@prod, pid:3336]
48. xdg-desktop-portal  [0.3.68, bernie@prod, pid:6040]
49. gnome-shell [0.3.68, bernie@prod, pid:3162]
50. Terminal[0.3.68, bernie@prod, pid:3555]
51. Mutter  [0.3.68, bernie@prod, pid:3162]
52. gjs [0.3.68, bernie@prod, pid:3502]
53. Firefox [0.3.68, bernie@prod, 
pid:215299]
57. wpctl   [0.3.68, bernie@prod, 
pid:330390]

** Affects: pipewire-media-session (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to pipewire-media-session in Ubuntu.
https://bugs.launchpad.net/bugs/2020621

Title:
  "wpctl status" causes line wrap with big PID values

Status in pipewire-media-session package in Ubuntu:
  New

Bug description:
  /usr/bin/wpctl is in package "wireplumber"
  cat /proc/sys/kernel/pid_max 
  4194304
  Ubuntu 22.04LTS has PID value up to 4Mi (7 digit decimal)
  on a std terminal with 80 colomns it wraps lines if more then 5 digits for 
PID in my case.

  please fix the output of "wpctl status" for 7 digit PID value without line 
wrap.
  I see 8 SPACE characters at begin_of_line which can be reduced.

   └─ Clients:
  31. pipewire[0.3.68, bernie@prod, 
pid:1434]
  33. WirePlumber [0.3.68, bernie@prod, 
pid:1432]
  34. WirePlumber [export][0.3.68, bernie@prod, 
pid:1432]
  46. GNOME Shell Volume Control  [0.3.68, bernie@prod, 
pid:3162]
  47. GNOME Volume Control Media Keys [0.3.68, bernie@prod, 
pid:3336]
  48. xdg-desktop-portal  [0.3.68, bernie@prod, 
pid:6040]
  49. gnome-shell [0.3.68, bernie@prod, 
pid:3162]
  50. Terminal[0.3.68, bernie@prod, 
pid:3555]
  51. Mutter  [0.3.68, bernie@prod, 
pid:3162]
  52. gjs [0.3.68, bernie@prod, 
pid:3502]
  53. Firefox [0.3.68, bernie@prod, 
pid:215299]
  57. wpctl   [0.3.68, bernie@prod, 
pid:330390]

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pipewire-media-session/+bug/2020621/+subscriptions


-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp


[Desktop-packages] [Bug 1946733] Re: gnome-terminal max_size and resize looses 1 row and 1 colomn

2021-11-19 Thread Bernhard Riegler
I assume an "integer division" cut down
my HW monitor has a screen resolution of 1920 x 1200 pixel.

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-terminal in Ubuntu.
https://bugs.launchpad.net/bugs/1946733

Title:
  gnome-terminal max_size and resize looses 1 row and 1 colomn

Status in gnome-terminal package in Ubuntu:
  New

Bug description:
  I installed "xterm" to get utility "resize" and have a comparison between 2 
terminal programs.
  xterm works. between the "resize" commands is double click on top bar 
(max.size, restore)
  bernie@prod:~$ resize
  COLUMNS=80;
  LINES=24;
  export COLUMNS LINES;
  bernie@prod:~$ resize
  COLUMNS=80;
  LINES=24;
  export COLUMNS LINES;
  bernie@prod:~$ resize
  COLUMNS=80;
  LINES=24;
  export COLUMNS LINES;
   stable columns,lines with xterm
  gnome-terminal has a bug. again (max.size, restore) with double-click on top 
bar.
  bernie@prod:~$ resize
  COLUMNS=80;
  LINES=24;
  export COLUMNS LINES;
  bernie@prod:~$ resize
  COLUMNS=79;
  LINES=23;
  export COLUMNS LINES;
  bernie@prod:~$ resize
  COLUMNS=78;
  LINES=22;
  export COLUMNS LINES;
  with every cycle the gnome-terminal looses 1 row and 1 column
  gnome-terminal info reports version 3.36.2
  platform is ubuntu 20.04 LTS
  bernie@prod:~$ lsb_release -rd
  Description:  Ubuntu 20.04.3 LTS
  Release:  20.04
  bernie@prod:~$ apt-cache policy gnome-terminal
  gnome-terminal:
Installiert:   3.36.2-1ubuntu1~20.04
Installationskandidat: 3.36.2-1ubuntu1~20.04
Versionstabelle:
   *** 3.36.2-1ubuntu1~20.04 500
  500 http://de.archive.ubuntu.com/ubuntu focal-updates/main amd64 
Packages
  100 /var/lib/dpkg/status
   3.36.1.1-1ubuntu1 500
  500 http://de.archive.ubuntu.com/ubuntu focal/main amd64 Packages
  please fix the gnome-terminal size shrinking and restore the same size as 
before
  thanks

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1946733/+subscriptions


-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp


[Desktop-packages] [Bug 1946733] [NEW] gnome-terminal max_size and resize looses 1 row and 1 colomn

2021-10-12 Thread Bernhard Riegler
Public bug reported:

I installed "xterm" to get utility "resize" and have a comparison between 2 
terminal programs.
xterm works. between the "resize" commands is double click on top bar 
(max.size, restore)
bernie@prod:~$ resize
COLUMNS=80;
LINES=24;
export COLUMNS LINES;
bernie@prod:~$ resize
COLUMNS=80;
LINES=24;
export COLUMNS LINES;
bernie@prod:~$ resize
COLUMNS=80;
LINES=24;
export COLUMNS LINES;
 stable columns,lines with xterm
gnome-terminal has a bug. again (max.size, restore) with double-click on top 
bar.
bernie@prod:~$ resize
COLUMNS=80;
LINES=24;
export COLUMNS LINES;
bernie@prod:~$ resize
COLUMNS=79;
LINES=23;
export COLUMNS LINES;
bernie@prod:~$ resize
COLUMNS=78;
LINES=22;
export COLUMNS LINES;
with every cycle the gnome-terminal looses 1 row and 1 column
gnome-terminal info reports version 3.36.2
platform is ubuntu 20.04 LTS
bernie@prod:~$ lsb_release -rd
Description:Ubuntu 20.04.3 LTS
Release:20.04
bernie@prod:~$ apt-cache policy gnome-terminal
gnome-terminal:
  Installiert:   3.36.2-1ubuntu1~20.04
  Installationskandidat: 3.36.2-1ubuntu1~20.04
  Versionstabelle:
 *** 3.36.2-1ubuntu1~20.04 500
500 http://de.archive.ubuntu.com/ubuntu focal-updates/main amd64 
Packages
100 /var/lib/dpkg/status
 3.36.1.1-1ubuntu1 500
500 http://de.archive.ubuntu.com/ubuntu focal/main amd64 Packages
please fix the gnome-terminal size shrinking and restore the same size as before
thanks

** Affects: gnome-terminal (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-terminal in Ubuntu.
https://bugs.launchpad.net/bugs/1946733

Title:
  gnome-terminal max_size and resize looses 1 row and 1 colomn

Status in gnome-terminal package in Ubuntu:
  New

Bug description:
  I installed "xterm" to get utility "resize" and have a comparison between 2 
terminal programs.
  xterm works. between the "resize" commands is double click on top bar 
(max.size, restore)
  bernie@prod:~$ resize
  COLUMNS=80;
  LINES=24;
  export COLUMNS LINES;
  bernie@prod:~$ resize
  COLUMNS=80;
  LINES=24;
  export COLUMNS LINES;
  bernie@prod:~$ resize
  COLUMNS=80;
  LINES=24;
  export COLUMNS LINES;
   stable columns,lines with xterm
  gnome-terminal has a bug. again (max.size, restore) with double-click on top 
bar.
  bernie@prod:~$ resize
  COLUMNS=80;
  LINES=24;
  export COLUMNS LINES;
  bernie@prod:~$ resize
  COLUMNS=79;
  LINES=23;
  export COLUMNS LINES;
  bernie@prod:~$ resize
  COLUMNS=78;
  LINES=22;
  export COLUMNS LINES;
  with every cycle the gnome-terminal looses 1 row and 1 column
  gnome-terminal info reports version 3.36.2
  platform is ubuntu 20.04 LTS
  bernie@prod:~$ lsb_release -rd
  Description:  Ubuntu 20.04.3 LTS
  Release:  20.04
  bernie@prod:~$ apt-cache policy gnome-terminal
  gnome-terminal:
Installiert:   3.36.2-1ubuntu1~20.04
Installationskandidat: 3.36.2-1ubuntu1~20.04
Versionstabelle:
   *** 3.36.2-1ubuntu1~20.04 500
  500 http://de.archive.ubuntu.com/ubuntu focal-updates/main amd64 
Packages
  100 /var/lib/dpkg/status
   3.36.1.1-1ubuntu1 500
  500 http://de.archive.ubuntu.com/ubuntu focal/main amd64 Packages
  please fix the gnome-terminal size shrinking and restore the same size as 
before
  thanks

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1946733/+subscriptions


-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp


[Desktop-packages] [Bug 1215882]

2021-04-16 Thread Bernhard Riegler
I completely agree with jonwestburne
CRITICAL because the user does not know the email was not sent.

I had again a server BUSY condition.
thunderbird version 78.7.1(64-bit) on GNU/Linux Ubuntu 20.04 LTS platform.
popup "load too high (#4.3.0)" and then the email is in 'sent' folder of my 
local Filesystem Archive.
my automatic "CC to sender" proves that it was not processed by server. I did 
not receive my CC.

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to thunderbird in Ubuntu.
https://bugs.launchpad.net/bugs/1215882

Title:
  Emails are silently discarded on 554 reply to STARTTLS

Status in Mozilla Thunderbird:
  Confirmed
Status in thunderbird package in Ubuntu:
  Triaged

Bug description:
  It seems that emails are silently discarded when the remote SMTP
  server replies with an error on STARTTLS. Here is an example smtp log
  created with NSPR_LOG_MODULES='smtp:5,timestamp':

  2013-08-23 11:10:25.548708 UTC - 43480896[7fe10164b370]: SMTP Connecting to: 
mail.trialphaenergy.com
  2013-08-23 11:10:26.513993 UTC - 43480896[7fe10164b370]: SMTP entering state: 0
  2013-08-23 11:10:26.514026 UTC - 43480896[7fe10164b370]: SMTP Response: 220 
mail.trialphaenergy.com Microsoft ESMTP MAIL Service ready at Fri, 23 Aug 2013 
04:10:25 -0700
  2013-08-23 11:10:26.514047 UTC - 43480896[7fe10164b370]: SMTP entering state: 
14
  2013-08-23 11:10:26.514069 UTC - 43480896[7fe10164b370]: SMTP Send: EHLO 
[10.11.206.9]
  2013-08-23 11:10:27.144751 UTC - 43480896[7fe10164b370]: SMTP entering state: 0
  2013-08-23 11:10:27.144791 UTC - 43480896[7fe10164b370]: SMTP Response: 
250-mail.trialphaenergy.com Hello [10.11.10.19]
  2013-08-23 11:10:27.144808 UTC - 43480896[7fe10164b370]: SMTP entering state: 0
  2013-08-23 11:10:27.144817 UTC - 43480896[7fe10164b370]: SMTP Response: 
250-SIZE
  2013-08-23 11:10:27.144828 UTC - 43480896[7fe10164b370]: SMTP entering state: 0
  2013-08-23 11:10:27.144839 UTC - 43480896[7fe10164b370]: SMTP Response: 
250-PIPELINING
  2013-08-23 11:10:27.144846 UTC - 43480896[7fe10164b370]: SMTP entering state: 0
  2013-08-23 11:10:27.144851 UTC - 43480896[7fe10164b370]: SMTP Response: 
250-DSN
  2013-08-23 11:10:27.144857 UTC - 43480896[7fe10164b370]: SMTP entering state: 0
  2013-08-23 11:10:27.144862 UTC - 43480896[7fe10164b370]: SMTP Response: 
250-ENHANCEDSTATUSCODES
  2013-08-23 11:10:27.144868 UTC - 43480896[7fe10164b370]: SMTP entering state: 0
  2013-08-23 11:10:27.144885 UTC - 43480896[7fe10164b370]: SMTP Response: 
250-STARTTLS
  2013-08-23 11:10:27.144889 UTC - 43480896[7fe10164b370]: SMTP entering state: 0
  2013-08-23 11:10:27.144893 UTC - 43480896[7fe10164b370]: SMTP Response: 
250-AUTH NTLM
  2013-08-23 11:10:27.144897 UTC - 43480896[7fe10164b370]: SMTP entering state: 0
  2013-08-23 11:10:27.144900 UTC - 43480896[7fe10164b370]: SMTP Response: 
250-8BITMIME
  2013-08-23 11:10:27.144904 UTC - 43480896[7fe10164b370]: SMTP entering state: 0
  2013-08-23 11:10:27.144920 UTC - 43480896[7fe10164b370]: SMTP Response: 
250-BINARYMIME
  2013-08-23 11:10:27.144926 UTC - 43480896[7fe10164b370]: SMTP entering state: 0
  2013-08-23 11:10:27.144931 UTC - 43480896[7fe10164b370]: SMTP Response: 250 
CHUNKING
  2013-08-23 11:10:27.144936 UTC - 43480896[7fe10164b370]: SMTP entering state: 
4
  2013-08-23 11:10:27.144961 UTC - 43480896[7fe10164b370]: SMTP entering state: 
21
  2013-08-23 11:10:27.144968 UTC - 43480896[7fe10164b370]: SMTP Send: STARTTLS
  2013-08-23 11:10:27.757848 UTC - 43480896[7fe10164b370]: SMTP entering state: 0
  2013-08-23 11:10:27.757881 UTC - 43480896[7fe10164b370]: SMTP Response: 554 
Policy violation. Email Session ID: {521742ED-1-F0B0B0A-}
  2013-08-23 11:10:27.757893 UTC - 43480896[7fe10164b370]: SMTP entering state: 
19
  2013-08-23 11:10:27.757900 UTC - 43480896[7fe10164b370]: SMTP entering state: 
21
  2013-08-23 11:10:27.757905 UTC - 43480896[7fe10164b370]: SMTP Send: QUIT
  2013-08-23 11:10:27.757915 UTC - 43480896[7fe10164b370]: SMTP entering state: 0

  
  The UI, however, gives no indication of failure and closes the compose window 
after the apparent successful submission to the smtp server.

  
  If the user has not configured a Sent folder this results in data loss. Even 
if the user has configured a sent folder, he receives no indication that the 
email has not been sent.

  ProblemType: Bug
  DistroRelease: Ubuntu 13.04
  Package: thunderbird 17.0.8+build1-0ubuntu0.13.04.1
  ProcVersionSignature: Ubuntu 3.8.0-27.40-generic 3.8.13.4
  Uname: Linux 3.8.0-27-generic x86_64
  AddonCompatCheckDisabled: False
  ApportVersion: 2.9.2-0ubuntu8.3
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  nikratio   2425 F pulseaudio
  BuildID: 20130803220711
  Channel: Unavailable
  Date: Fri Aug 23 13:05:30 2013
  ForcedLayersAccel: False
  IfupdownConfig:
   # interfaces(5) file used by ifup(8) and ifdown(8)
   auto lo
   iface lo inet loopback
  

[Desktop-packages] [Bug 1215882]

2021-03-19 Thread Bernhard Riegler
after thinking about the possibilities for this server "transient failure" 
I would recommend rescue in the local Filesystem on server status (#4.3.0) 
independent of config for folder 'sent' and folder 'draft'
make a subdirectory "rescue" in the local File System below local ARCHIVE 
folder and put the email in here.
this is independent of the server BUSY problem.
the file in 'rescue' folder can now easily retried later and is not 'lost on 
transit'

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to thunderbird in Ubuntu.
https://bugs.launchpad.net/bugs/1215882

Title:
  Emails are silently discarded on 554 reply to STARTTLS

Status in Mozilla Thunderbird:
  Confirmed
Status in thunderbird package in Ubuntu:
  Triaged

Bug description:
  It seems that emails are silently discarded when the remote SMTP
  server replies with an error on STARTTLS. Here is an example smtp log
  created with NSPR_LOG_MODULES='smtp:5,timestamp':

  2013-08-23 11:10:25.548708 UTC - 43480896[7fe10164b370]: SMTP Connecting to: 
mail.trialphaenergy.com
  2013-08-23 11:10:26.513993 UTC - 43480896[7fe10164b370]: SMTP entering state: 0
  2013-08-23 11:10:26.514026 UTC - 43480896[7fe10164b370]: SMTP Response: 220 
mail.trialphaenergy.com Microsoft ESMTP MAIL Service ready at Fri, 23 Aug 2013 
04:10:25 -0700
  2013-08-23 11:10:26.514047 UTC - 43480896[7fe10164b370]: SMTP entering state: 
14
  2013-08-23 11:10:26.514069 UTC - 43480896[7fe10164b370]: SMTP Send: EHLO 
[10.11.206.9]
  2013-08-23 11:10:27.144751 UTC - 43480896[7fe10164b370]: SMTP entering state: 0
  2013-08-23 11:10:27.144791 UTC - 43480896[7fe10164b370]: SMTP Response: 
250-mail.trialphaenergy.com Hello [10.11.10.19]
  2013-08-23 11:10:27.144808 UTC - 43480896[7fe10164b370]: SMTP entering state: 0
  2013-08-23 11:10:27.144817 UTC - 43480896[7fe10164b370]: SMTP Response: 
250-SIZE
  2013-08-23 11:10:27.144828 UTC - 43480896[7fe10164b370]: SMTP entering state: 0
  2013-08-23 11:10:27.144839 UTC - 43480896[7fe10164b370]: SMTP Response: 
250-PIPELINING
  2013-08-23 11:10:27.144846 UTC - 43480896[7fe10164b370]: SMTP entering state: 0
  2013-08-23 11:10:27.144851 UTC - 43480896[7fe10164b370]: SMTP Response: 
250-DSN
  2013-08-23 11:10:27.144857 UTC - 43480896[7fe10164b370]: SMTP entering state: 0
  2013-08-23 11:10:27.144862 UTC - 43480896[7fe10164b370]: SMTP Response: 
250-ENHANCEDSTATUSCODES
  2013-08-23 11:10:27.144868 UTC - 43480896[7fe10164b370]: SMTP entering state: 0
  2013-08-23 11:10:27.144885 UTC - 43480896[7fe10164b370]: SMTP Response: 
250-STARTTLS
  2013-08-23 11:10:27.144889 UTC - 43480896[7fe10164b370]: SMTP entering state: 0
  2013-08-23 11:10:27.144893 UTC - 43480896[7fe10164b370]: SMTP Response: 
250-AUTH NTLM
  2013-08-23 11:10:27.144897 UTC - 43480896[7fe10164b370]: SMTP entering state: 0
  2013-08-23 11:10:27.144900 UTC - 43480896[7fe10164b370]: SMTP Response: 
250-8BITMIME
  2013-08-23 11:10:27.144904 UTC - 43480896[7fe10164b370]: SMTP entering state: 0
  2013-08-23 11:10:27.144920 UTC - 43480896[7fe10164b370]: SMTP Response: 
250-BINARYMIME
  2013-08-23 11:10:27.144926 UTC - 43480896[7fe10164b370]: SMTP entering state: 0
  2013-08-23 11:10:27.144931 UTC - 43480896[7fe10164b370]: SMTP Response: 250 
CHUNKING
  2013-08-23 11:10:27.144936 UTC - 43480896[7fe10164b370]: SMTP entering state: 
4
  2013-08-23 11:10:27.144961 UTC - 43480896[7fe10164b370]: SMTP entering state: 
21
  2013-08-23 11:10:27.144968 UTC - 43480896[7fe10164b370]: SMTP Send: STARTTLS
  2013-08-23 11:10:27.757848 UTC - 43480896[7fe10164b370]: SMTP entering state: 0
  2013-08-23 11:10:27.757881 UTC - 43480896[7fe10164b370]: SMTP Response: 554 
Policy violation. Email Session ID: {521742ED-1-F0B0B0A-}
  2013-08-23 11:10:27.757893 UTC - 43480896[7fe10164b370]: SMTP entering state: 
19
  2013-08-23 11:10:27.757900 UTC - 43480896[7fe10164b370]: SMTP entering state: 
21
  2013-08-23 11:10:27.757905 UTC - 43480896[7fe10164b370]: SMTP Send: QUIT
  2013-08-23 11:10:27.757915 UTC - 43480896[7fe10164b370]: SMTP entering state: 0

  
  The UI, however, gives no indication of failure and closes the compose window 
after the apparent successful submission to the smtp server.

  
  If the user has not configured a Sent folder this results in data loss. Even 
if the user has configured a sent folder, he receives no indication that the 
email has not been sent.

  ProblemType: Bug
  DistroRelease: Ubuntu 13.04
  Package: thunderbird 17.0.8+build1-0ubuntu0.13.04.1
  ProcVersionSignature: Ubuntu 3.8.0-27.40-generic 3.8.13.4
  Uname: Linux 3.8.0-27-generic x86_64
  AddonCompatCheckDisabled: False
  ApportVersion: 2.9.2-0ubuntu8.3
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  nikratio   2425 F pulseaudio
  BuildID: 20130803220711
  Channel: Unavailable
  Date: Fri Aug 23 13:05:30 2013
  ForcedLayersAccel: False
  IfupdownConfig:
   # interfaces(5) file used by ifup(8) and ifdown(8)
   auto lo
  

[Desktop-packages] [Bug 1215882]

2021-03-19 Thread Bernhard Riegler
I have the following environment: Europe, Austria, A1 Provider, sending with 
Thunderbird 78.7.1(64-bit) on GNU/Linux Ubuntu 20.04 LTS
the outgoing configuration is SMTP port 587 with STARTTLS

everything works fine, but sometimes the Provider SMTP Server is BUSY.
I get in thunderbird client a pop up "load too high (#4.3.0)" and then the 
email is in 'sent' folder.
as I always put myself a CC in every email, I can guarantee that the email was 
not processed by the SMTP server.
this matches the pop up message.
this is a transient SMTP server error.
thunderbird client knows this and shall not put this failed output into folder 
'sent' , but into folder 'draft' for later retry.

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to thunderbird in Ubuntu.
https://bugs.launchpad.net/bugs/1215882

Title:
  Emails are silently discarded on 554 reply to STARTTLS

Status in Mozilla Thunderbird:
  Confirmed
Status in thunderbird package in Ubuntu:
  Triaged

Bug description:
  It seems that emails are silently discarded when the remote SMTP
  server replies with an error on STARTTLS. Here is an example smtp log
  created with NSPR_LOG_MODULES='smtp:5,timestamp':

  2013-08-23 11:10:25.548708 UTC - 43480896[7fe10164b370]: SMTP Connecting to: 
mail.trialphaenergy.com
  2013-08-23 11:10:26.513993 UTC - 43480896[7fe10164b370]: SMTP entering state: 0
  2013-08-23 11:10:26.514026 UTC - 43480896[7fe10164b370]: SMTP Response: 220 
mail.trialphaenergy.com Microsoft ESMTP MAIL Service ready at Fri, 23 Aug 2013 
04:10:25 -0700
  2013-08-23 11:10:26.514047 UTC - 43480896[7fe10164b370]: SMTP entering state: 
14
  2013-08-23 11:10:26.514069 UTC - 43480896[7fe10164b370]: SMTP Send: EHLO 
[10.11.206.9]
  2013-08-23 11:10:27.144751 UTC - 43480896[7fe10164b370]: SMTP entering state: 0
  2013-08-23 11:10:27.144791 UTC - 43480896[7fe10164b370]: SMTP Response: 
250-mail.trialphaenergy.com Hello [10.11.10.19]
  2013-08-23 11:10:27.144808 UTC - 43480896[7fe10164b370]: SMTP entering state: 0
  2013-08-23 11:10:27.144817 UTC - 43480896[7fe10164b370]: SMTP Response: 
250-SIZE
  2013-08-23 11:10:27.144828 UTC - 43480896[7fe10164b370]: SMTP entering state: 0
  2013-08-23 11:10:27.144839 UTC - 43480896[7fe10164b370]: SMTP Response: 
250-PIPELINING
  2013-08-23 11:10:27.144846 UTC - 43480896[7fe10164b370]: SMTP entering state: 0
  2013-08-23 11:10:27.144851 UTC - 43480896[7fe10164b370]: SMTP Response: 
250-DSN
  2013-08-23 11:10:27.144857 UTC - 43480896[7fe10164b370]: SMTP entering state: 0
  2013-08-23 11:10:27.144862 UTC - 43480896[7fe10164b370]: SMTP Response: 
250-ENHANCEDSTATUSCODES
  2013-08-23 11:10:27.144868 UTC - 43480896[7fe10164b370]: SMTP entering state: 0
  2013-08-23 11:10:27.144885 UTC - 43480896[7fe10164b370]: SMTP Response: 
250-STARTTLS
  2013-08-23 11:10:27.144889 UTC - 43480896[7fe10164b370]: SMTP entering state: 0
  2013-08-23 11:10:27.144893 UTC - 43480896[7fe10164b370]: SMTP Response: 
250-AUTH NTLM
  2013-08-23 11:10:27.144897 UTC - 43480896[7fe10164b370]: SMTP entering state: 0
  2013-08-23 11:10:27.144900 UTC - 43480896[7fe10164b370]: SMTP Response: 
250-8BITMIME
  2013-08-23 11:10:27.144904 UTC - 43480896[7fe10164b370]: SMTP entering state: 0
  2013-08-23 11:10:27.144920 UTC - 43480896[7fe10164b370]: SMTP Response: 
250-BINARYMIME
  2013-08-23 11:10:27.144926 UTC - 43480896[7fe10164b370]: SMTP entering state: 0
  2013-08-23 11:10:27.144931 UTC - 43480896[7fe10164b370]: SMTP Response: 250 
CHUNKING
  2013-08-23 11:10:27.144936 UTC - 43480896[7fe10164b370]: SMTP entering state: 
4
  2013-08-23 11:10:27.144961 UTC - 43480896[7fe10164b370]: SMTP entering state: 
21
  2013-08-23 11:10:27.144968 UTC - 43480896[7fe10164b370]: SMTP Send: STARTTLS
  2013-08-23 11:10:27.757848 UTC - 43480896[7fe10164b370]: SMTP entering state: 0
  2013-08-23 11:10:27.757881 UTC - 43480896[7fe10164b370]: SMTP Response: 554 
Policy violation. Email Session ID: {521742ED-1-F0B0B0A-}
  2013-08-23 11:10:27.757893 UTC - 43480896[7fe10164b370]: SMTP entering state: 
19
  2013-08-23 11:10:27.757900 UTC - 43480896[7fe10164b370]: SMTP entering state: 
21
  2013-08-23 11:10:27.757905 UTC - 43480896[7fe10164b370]: SMTP Send: QUIT
  2013-08-23 11:10:27.757915 UTC - 43480896[7fe10164b370]: SMTP entering state: 0

  
  The UI, however, gives no indication of failure and closes the compose window 
after the apparent successful submission to the smtp server.

  
  If the user has not configured a Sent folder this results in data loss. Even 
if the user has configured a sent folder, he receives no indication that the 
email has not been sent.

  ProblemType: Bug
  DistroRelease: Ubuntu 13.04
  Package: thunderbird 17.0.8+build1-0ubuntu0.13.04.1
  ProcVersionSignature: Ubuntu 3.8.0-27.40-generic 3.8.13.4
  Uname: Linux 3.8.0-27-generic x86_64
  AddonCompatCheckDisabled: False
  ApportVersion: 2.9.2-0ubuntu8.3
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND