Running Pmail v.4.91.1746 on Windows 10 PC.
The following happens on two separate machines running the same set-up, one a laptop, one a desktop.

When sending SMTP [edited], Pegasus hangs (aqua ring, no functionality, not even X out) for a time period - momentary with small size messages, longer with bigger attachments. The short ones are tolerable, but when sending a 10MB attachment, the total message send time can be several minutes of PMail hung up (progress clocks in short bursts, not slow crawl). If I try to use PMail during the 'pauses', it grays out and starts acting locked up. But either way, eventually coughs out the email.

The interesting bit is it only happens sending via one host SMTP [edited] server (to which I recently switched one account).

I have a different host with which sending pop this does not happen.

I have worked with the problem host (he's a small shop and very hands on) and we are not finding anything in logs that explains what's going. His end just shows a really slow pop transfer with no messages from my end to hold, or of any issue. On my end each package transfer is recorded, just with inexplicable time gaps between them when it hits the large attachment email. Doing this live with the host on the phone watching logs his logs are showing his system is just waiting on me, no error or problem indicator from me, nor on his end indicating it's his system pausing things.

I'm not too technically experienced (but a quick learner), he is experienced, and from what we see it seems like there's a PMail program / code issue with something about transferring to his server (which PMail does not have with the other host).

Any ideas?

The topic "Pmail hangs on sending pop" is confusing. What do you mean by "pop" here and "sending pop" used later in your post. If "pop" means POP3, well that is not involved in sending, SMTP does the sending. The fact that the delay only occurs with one SMTP server indicates that problem is not with Pegasus Mail but with that server, or the connection to it. I'm sure you have confirmed with the provider what port to use as well as whether security should be SSL or STARTTLS so the only other thing that comes to my mind is whether you are using an anti-malware product that is scanning outgoing traffic on the port being used by the problem SMTP host. Is the SMTP host that is working fine using the same port as than the problem one?

1. "hang" can be interpreted as simply the time required for Pegasus Mail to convert a large binary attachment into text (e.g., Base64);
2. If the attachment is already large, the fact that it needs to be converted to text will result in a considerable increase in bytes, something like +33.33%, which will require even more transmission time. In these cases, a longer timeout is advisable. If hanging is true, than the use of IdW's MiniDump/PmDebug is a must;
3. Email servers reject long messages and especially long attachments, whether numerous and/or large;
4. Finally, would you be willing to share a session log (please remove authentication data) so that we can assess where the problem lies, whether in Pmail or your email provider?

Thanks for the replies!

Something is going on between PMail and this new host, but we can't seem to find anything in the actual SMTP transfer process going wrong. In an another analogy, it's like (again: looks like it, not claiming it) PMail itself (the software code) is allergic to this host in a way which causes PMail to repeatedly 'stick' after pumping out a bit of message, then wake up and keep going.

I'll post my logs in a bit (soon as I figure out how and have a second cuppa for clarity.)
I'll see if my host is able to get on this thread as well; he'll provide a much better technical perspective from his end.

Abbreviated log file during SMTP send when using the "problem" host.
I took out what I think is the secure access info, if I should take out more please let me know so I can take it down.

I snipped out the boring bits where packets happily chug along in microsecond bursts. I left the bits where there are inexplicable ~40 second pauses between two packets. This is an excerpt of one. 12:43:45.580 right to 12:44:25.390. 40 seconds of pause with no logged issue on PMail's side (nor any request/notification from PMail or command to PMail on host's side)

12:43:45.563: << fJAOSPUA8Rpp4lCaf1d5Lprj2g+6NP71T3XPr9Y6OIgDxI7qWeXhERW+zHGFmR7Os3I9Gz02<cr><lf>
12:43:45.580: << N3F0k+ERqSeyy7s+4FlMg1unT95xbH3aqW91Vb7HyHnmRz4yqlTRl5PqUMlrW+7ce/Yx5eCz<cr><lf>
12:44:25.390: << pkzz2O+jZieHHX2urTIfW6w+4tJd8dNI8lR6o4Uk3sIfGmwydP5P7vw4V6k/pWjkgE+J18Tx<cr><lf>
12:44:25.394: << KLeNC71CwwY1EfcVqCN2A0zKqLzFb/V3hoftmRpBHfVXsMVX/pHuc0jR0jgxGsfkUr32Xgsa<cr><lf>

[Edit]TCP-250923-1243-6 Imageway - Trimmed.txt

[Edit]FWIW I scanned through the log using the other host with no apparent issues thinking maybe there were also pauses, just too short to notice. No luck. Longest pause I could find was < 0.1

I uploaded a file, but don't see it in the thread. Is it available?

Look in the SMTP host configurations to see if the problem one is using port 465 but the good one is not. I suggest this because...
... research done just now indicates that port 465 is the SMTP port being scanned by default by AVG.
... AVG was a problem for me years ago, and was very difficult to get completely uninstalled. IIRC, its email shield would not uninstall if it was enabled when AVG was uninstalled. I think I had to use an AVG removal tool. A quick search found two:

• AVG Clear authored by AVG Technologies according to this site: https://www.bleepingcomputer.com/download/avg-clear/.
• AVG Uninstall Tool is linked to on this AVG support site (click the "Articles" link on the left of the page for details): https://support.avg.com/kA60N0000004aGy?name=uninstall-avg-software-clear-remover&language=en_US

It isn't. Some file types are not allowed so perhaps that is the problem. Pasting it into a reply is an option. Remove the content between the "AUTH LOGIN" entry and the "Authentication Successful". It contains your credentials, likely encoded but in easily decodable form.

Thanks for the efforts, btw

It probably isn't the issue since both are using port 465 but only one is being affected with the slow sending issue.

That didn't work either. Might have to copy/paste the contents into a reply, removing the authentication credentials in the process.

I'm actually getting a new machine delivered today for unrelated reasons. Going to get that one up and running and first application install will be PMail for a test.

Sorry, I didn't look back for an edited post.

Nothing jumps out at me in the session log that would explain the slowdown but analyzing these logs is not one of my strengths so I'm hopeful some spots something that I don't.