Re: More/new smtp issues

[Jack <ostroffjh users sourceforge net>]

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 frontier.com 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:
> [snip]
> > ** (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 smtp.gmail.com
> > ** (balsa:2296): DEBUG: libbalsa_smtp_server_unlock: unlock gmail
> > ** (balsa:2296): DEBUG: finalised connection to  
> > smtp.mail.yahoo.com:587
> > ** (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 smtp.frontier.com
> > ** (balsa:2296): DEBUG: R '220 relay03.roch.ny.frontiernet.net ESMTP  
> > Postfix'
> > ** (balsa:2296): DEBUG: W 'EHLO ffortso4'
> > ** (balsa:2296): DEBUG: R '250-relay03.roch.ny.frontiernet.net'
> > ** (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]: 'relay03.roch.ny.frontiernet.net 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 smtp.frontier.com
> 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:
>
> [snip]
> --- 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");
>      g_free(greeting);
>      if (result) {
>          GList *this_msg;
> [/snip]
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.
> Cheers,
> Albrecht.

Jack

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?