@phill Made it into the next beta round yesterday and must say, my first impression is quite positive. I’m using it on an iOS17 device, but it works well.
What doesn't seem to work, is to not show sender images. I switched it of but they still show up in the messages list. And I would prefer lighter headlines in the list views. They are really bold. 😁
Setting names for accounts would be another nice addition. I have mail accounts with very unpleasant login mail addresses. 😉
@schalksernst that’s great to hear!
There’s two switches for contact images: one for Mailboxes and one per Smartbox. It sounds like maybe you’d expect the Mailboxes one to apply globally?
And nicknames for accounts are coming in the next build. Will see what we can do about lighter headlines.
@phill Oh no! Now I feel dumb. Hadn't seen that option for lists. Maybe it was completely covered by the keyboard. Now the lists are just as I liked them to be. Wow. So easy. I like! 😊
@schalksernst ha don’t feel dumb! Always tricky to figure out right way to expose settings. Glad you like 😀
@phill So after day two with it, I think this could become my new mail client to go. I'm sure it gets snappier without the extensive logging.
One thing I'd wish for is a way to define the default sender address for new mail and which address should be used when replying (should be the one the mail was sent to before in most cases).
But again: The UI/UX is great. 😊
@schalksernst that's awesome to hear!
Once we're out of the heavy-handed troubleshooting phase I can dial logging back and things will be a lot more snappy.
Latest build (33) adds default sender option (Settings > Composing). Replies should always default from the account they were received on. Let me know if you're not seeing that.
I've also added account nicknames/descriptions too :-)
@phill For my webhoster I have to setup mailboxe user logins in the form [userID]p[mailboxID]@[vmID].[hosterdomain] and then have to add the alias I wish to use for mail. Replying with that account exposes the "login ID", which is not a nice email address.
2/2
@schalksernst ahh gotcha. Okay I’ll get that sorted!
@phill Great to hear. Thank you! Not sure if that's a common use case. Most of the mail users don't have aliases I guess. So this is not really a priority. But the closer a launch comes the more welcome it would be. 😁
@phill Whoa! You’re just too quick with the aliases! The improvements in the latest update make mailing so much more comfortable. Again: I'm so impressed. This app is a real gem!
@schalksernst so glad! I did a notice a small issue this morning where if you don’t have the alias setup, it defaults to completely the wrong account, but I’ll fix that in next update. 🤓
@phill Those pesky aliases! 😁
Just as a thought: Would it be useful to see the active mail address when replying? Maybe this is really not important. I just thought about right now because the views between replying and new mail are different. While replying there’s no quick way to tell if the sender address is right unless you tap on the recipient's name. What do you think?
@schalksernst the thinking was 99% of the time it’s unnecessary to change it as long as it Does The Right Thing™ (that is just reply from whatever address it was originally sent to). But definitely open to feedback on it!
@phill That argument is totally valid! Not too much visual distraction. And if you really need it you know where to find it. So I take back that question and never asked. 😁
@schalksernst ha no definitely something I wondered too! Will keep an eye out for it in the feedback.
@phill Then hopefully most users like the actual implementation. 😉 Maybe the "problem" behind it falls into the same line as the alias thing. Most users just don't have a need for it. So hiding it sounds logical.
@phill There seems to be a problem with special characters (umlauts). And with attachments. They just show as "data".
@schalksernst if you can access the message via the providers interface and click “Show Original / Raw Message” (or something like that) and search for "content-type", what value do you see there? What does “charset” say?
@phill RAW Message shows:
Content-Type: multipart/mixed;
some lines later:
This is a multi-part message in MIME format.
Content-Type: multipart/alternative;
then again later:
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
@schalksernst sorry last question: if you search specifically for “text/html” does the content-type for that also say utf-8? is the transfer-encoding also 8bit?
@phill Sorry, completely missed that part.
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
And those missing images and attachments have Content-Transfer-Encoding: base64
@schalksernst hmm that is a bit odd, i'd expect that combo to work okay. Let me try replicate my end and if I can't I'll give you another ping.
Thanks!
@phill The raw data is interesting. Haven't looked into it often.
This particular message is sent via googlemail but with own domain and they used Thunderbird as mail client. Attachments are inline PNGs, 2x XLS-files and 1x PDF.
Lovely ingredients for reproducing. 😁
@schalksernst haha I'm used to all sorts of possible combinations now 🥲
(Thanks for the extra info!)
@schalksernst so after a little digging I’m able to recreate this. There’s a part in the pipeline that is expecting 7bit octets, and it’s getting 8. I haven’t actually seen an 8bit email in the wild before (they’re relatively ‘new’ by email standards), so it’s helpful to know they come from Thunderbird. Thanks for spotting it!
@phill Yay! Finally something useful to have special characters in our alphabet. And if only for debugging purposes. 😁
@phill Yeah! Every update makes the app better and better. It's great to see it evolving. :)
May I suggest to take the aliases into the list for default addresses, too? Also for replying. I can only assume it's not that trivial. I can only describe why this matters.
I have my iCloud-ID, but I'm only using an alias there for mail. So every time I reply to a mail the sender address defaults to the ID, which should not be used.
1/2