Re: More/new smtp issues

Hello Albrecht,

Thanks again (as usual) for all your assistance. The primary bottom line here is that between Frontier/Yahoo/Verizon, I'm going to completely dump them as soon as I can manage. Getting reasonable support is essentially impossible, and I've come to the conclusion I need to run away as fast as possible, and stop wasting my time, as interesting a puzzle as it may be. However, a few more details below.

On 2017.10.28 09:44, Albrecht Dreß wrote:
Hi Jack:
Am 27.10.17 23:12 schrieb(en) Jack:
Up until a few weeks/months ago, I had no problem sending mail through my account. At some point, however, it just stopped going, but did not provide any error message. I have looked through previous email threads on this list about this very topic, but nothing there seems to make any difference now.
Can you narrow down the point where the issue occurred, in particular if it is linked to a certain Git version?
I thought stuff worked with vanilla 2.5.3, but I really think the problem was changes on the server(s) and not any changes in Balsa.

Using Albrecht's suggestion of "G_MESSAGES_DEBUG=all balsa > LOG.out 2>&" (modified to combine stdout and stderror to one file) and then trimming down the file, I get the following when starting balsa, toggling off the flag on the message in the outbox, and trying to send again:
** (balsa:2296): DEBUG: libbalsa_smtp_server_trylock: lock frontier: 1
** (balsa:2296): DEBUG: libbalsa_smtp_server_trylock: lock gmail: 1
** (balsa:2296): DEBUG: libbalsa_smtp_server_trylock: lock yahoo: 1
** (balsa:2296): DEBUG: finalised connection to
** (balsa:2296): DEBUG: libbalsa_smtp_server_unlock: unlock gmail
** (balsa:2296): DEBUG: finalised connection to
** (balsa:2296): DEBUG: libbalsa_smtp_server_unlock: unlock yahoo
This is the normal behaviour when you try to send queues messages. The process tries to acquire a lock for each of your SMTP servers as to avoid races before running the connection check (which may take some time). If no pending message for a particular server is in the queue, the lock is released. The “finalised connection to…” indicates that the corresponding libnetclient object has been destroyed. Note that no network connection has been established for them.
Good information.

** (balsa:2296): DEBUG: balsa_send_message_real: starting
** (balsa:2296): DEBUG: connected to
** (balsa:2296): DEBUG: R '220 ESMTP Postfix'
** (balsa:2296): DEBUG: W 'EHLO ffortso4'
** (balsa:2296): DEBUG: R ''
** (balsa:2296): DEBUG: R '250-PIPELINING'
** (balsa:2296): DEBUG: R '250-SIZE 36350634'
** (balsa:2296): DEBUG: R '250-ETRN'
** (balsa:2296): DEBUG: R '250-AUTH PLAIN LOGIN'
** (balsa:2296): DEBUG: R '250-AUTH=PLAIN LOGIN'
** (balsa:2296): DEBUG: R '250-ENHANCEDSTATUSCODES'
** (balsa:2296): DEBUG: R '250-8BITMIME'
** (balsa:2296): DEBUG: R '250 DSN'
** (balsa:2296): DEBUG: balsa_send_message_real: connect = 0 [0xc02480]: ' ESMTP Postfix'
Hmmm, “connect = 0” means that starting the connection failed. Balsa /should/ show you an error message in this case
More below, but it seems sometimes the connection is just dropped with not enough info to give any useful error ("connection dropped" I don't consider useful...)

How is the SMTP server configured? If the “Security” setting is “TLS required”, the explanation would be that the remote server does not offer the STARTTLS command, i.e. it expects you to send your authentication *without* encryption (which would be a *really* bad idea!). However, the call to net_client_smtp_connect() (in libbalsa/send.c, line 1008) should return the error message “remote server does not support STARTTLS” in this case.
After adding your patch from below, I still had a few tries without useful errors, and I still have no idea what was going on. However, I finally created a new user, with only the frontier pop3 and smtp, and indeed, I finally saw the explicit message about not supporting STLS or STARTTLS. Right now, frontier only seems to work for me with POP3S or SMTPS. I no longer care enough to try to figure out why. As I read the rest of the debug stuff, it seems at least that the SMTP connection is sending the message encrypted, but it looks like the POP3 retrievals are not encrypted. It won't be a problem for me for much longer.

** (balsa:2296): DEBUG: libbalsa_smtp_server_unlock: unlock frontier
** (balsa:2296): DEBUG: W 'QUIT'
** (balsa:2296): DEBUG: R '221 2.0.0 Bye'
** (balsa:2296): DEBUG: finalised connection to
O.k., this looks normal.

One question is that I don't understand why libbalsa_smtp_server_trylock shows up for all three defined outgoing mail servers. frontier is the one in question. The other two work fine.
See explanation above.

The issue is that I get no error message at all - balsa just sets the flag on the message and leaves it in the outbox.
This is really strange indeed. How did you configure Balsa regarding the handling of error messages?
The only relevant setting I can find is "Debug" on the Misc config tab, and it is checked.

You could apply the following (untested) patch as to display the error message in the debug output:

--- a/libbalsa/send.c
+++ b/libbalsa/send.c
@@ -1006,7 +1006,8 @@ balsa_send_message_real(SendMessageInfo *info)

     /* connect the SMTP server */
result = net_client_smtp_connect(info->session, &greeting, &error); - g_debug("%s: connect = %d [%p]: '%s'", __func__, result, info->items, greeting); + g_debug("%s: connect = %d [%p]: '%s' (%s)", __func__, result, info->items, greeting,
+           (error != NULL) ? error->message : "no error");
     if (result) {
         GList *this_msg;
Aside from not seeming to work the first few times, this did seem to help.

This is with balsa 2.5.3a-187-g7291ba34 compiled from git. I don't think that is quite the latest, so slap my wrist if there are more recent commits which might make a difference.
At first glance nothing which would explain your issue. Updating to a recent git version would be a good idea, though.
I'm not using current git head, but as I said, I think my underlying issues were not due to Balsa, but due to Frontier/Yahoo/Verizon.



Minor point - Albrecht replied to me and cc'd the list, so when I did my usual response by hitting "G" to reply to the group, balsa didn't know the message came from the list, so when I finally hit "Send" nothing happened, because "To:" was blank, which I then have to enter manually. I'm curious if the list software is "smart" enough not to send a copy to anyone on the "to" (or maybe even "cc") list?

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]