Hi Iain, I have no direct answer to your question, but AOL apparently offers free accounts (so you can test this behaviour). Cheers, Arjen

I am in the process of doing so, unfortunately, I have no valid zip code, so the best I can get is an aol.co.uk account, and emails to this appear to work. I am getting the customer to set up a dummy account for me on their system so we can send me an invoice and see if it's their server, or the invoice print directly which fails.  Copy invoices and other emails work to this account.  

Back in the day, when in need of a US Zip code for test purposes, I always used: 1 Campus Martius 48226 Detroit MI

 1060 W Addison St, Chicago, IL 60613 Worked fine for the Blues Brothers !

Both good addresses, if the aol.co.uk test fails I may try those.  I was hoping someone would have encountered the problem, because I know the UPOPMAIL headers etc are pretty inflexible, so even if I work out what the issue is, I'm not sure I can fix it.... 

I'm wondering if this will work. We know Uniface doesn't support Hotmail and Office365, and it's related to security.  We've talked about this at user groups and so on as part of the work we want to do on Security. We've not picked this up off the backlog yet. I expect it to start after the TLS driver is completed.  I'm aware we need to do more in regards to functionality, I'm envisioning a new uPopMail, and keeping the current one for compatibility purposes, similar to what we did with LDAP. 

It's not using aol as an smtp server, it's purely sending mails to it as a client. So it shouldn't make a difference.  However, there are threads online about AOL requiring the MIME encoding parts of the email to be letter perfect in terms of the MIME part name and the number of carriage returns and ; signs. So I wonder if the UPOPMAIL encoding is somehow wrong.  So far my tests on aol.co.uk indicate I can send mails with attachments fine. I'm organising tests on aol.com jusing the zip codes above.