Freron MailMate

Comments and changes to this ticket

• 

  benny February 19th, 2011 @ 12:37 AM

  • State changed from “new” to “resolved”
  • Assigned user set to “benny”

  Actually MailMate blocks external references in many cases. The following is from the release notes:

  External references are blocked for a message if one or more of the following is true:

  • It is in a junk mailbox
  • It is marked $Junk
  • It is in an Inbox or in a mailbox for deleted messages without the $NotJunk flag.

  This is kind of a minimal implementation. I would like to make the rules above configurable, e.g., if one wants to block more or allow more by default.

  Let me know if you do not experience the behavior described above. I've marked the ticket as resolved.

  Feel free to create a new request for more configuration of junk handling. You can also comment on this ticket if you like.

  Btw: Thanks for trying out MailMate.

• You flagged this item as spam.
  

  Bill Cole February 19th, 2011 @ 04:59 AM

  I really meant what I wrote. No remote components should be retrieved for HTML mail without the user explicitly asking the program to do so. Trying to make a more subtle distinction so that the software will sometimes automatically fetch external content is a recipe for trouble. That's what Microsoft tried for a decade of tweaking Outlook and continuing to have spammers find holes.

  Obviously I cannot know exactly what logic is failing, but I have attached the evidence of a failure to follow the rules you state: a message in an INBOX with the flags \Deleted and \Seen causing a retrieval attempt and getting caught by LittleSnitch. So how did the message get in that state? Thunderbird was also looking at that Inbox, deemed the message to be spam, and marked the copy in the Inbox appropriately.

  I think the 'best practice" for mail clients in this area is well-established. Classic Eudora (before it became a TBird variant,) Outlook, GMail, Yahoo, and Thunderbird all work the same way: no external content is fetched unless and until the user actively requests it, unless there is some affirmative trustworthy reason to believe that the mail is safe. It is also helpful to keep in mind (as Qualcomm failed to at first) that the really problematic act is not display, but retrieval. In other words: don't fetch external content until the user demands it, but once that has been done, keep the external content around for re-use as needed.

  I feel the need to add: I have spent more time playing with MailMate than I have with any other mail client in a long time. It is a remarkably good MUA and shows more promise of being worth some time than anything else in active development. It is still rough and incomplete, but it is a VERY good start.

• 

  benny February 19th, 2011 @ 10:25 AM

  • State changed from “resolved” to “fixcommitted”

  Well, I feel I'm being pretty strict at the moment. I'm mostly getting
  requests for making MailMate better at recognizing emails from sources
  which have been trusted in the past. But I agree that any attempts to be
  smart in this area is a recipe for trouble. I'll probably end up with
  strict defaults and options to make it less strict.

  Your screenshot was very helpful. I think the problem is that the
  message has the \Deleted flag set. That means that the message is not
  shown in the Inbox (the universal one) and this is also the one used for
  my test of location. MailMate does not itself really use the \Deleted
  flag, so it has been set by another client (which explains why I did not
  notice this problem sooner). As a quick fix I now include all messages
  with the \Deleted flag in the set of untrusted messages. (I know you
  would like it to be stricter.)

  Let me know if you do not think this was the problem.

  And yes, when a message is blocked, MailMate does not fetch anything.

  Unrelated: Notice “View ▸ Distortion Mode”. It is kind of a
  proof-of-concept, but the purpose is exactly to help send screenshots
  (although mailbox names are not distorted).

  And thanks for the encouraging comment!

  [state:fixcommitted]

• 

  benny March 5th, 2011 @ 05:20 PM

  • State changed from “fixcommitted” to “fixreleased”

  [bulk edit]

• You flagged this item as spam.
  

  Bill Cole March 6th, 2011 @ 09:03 PM

  This is still broken AS A MATTER OF DESIGN Today I clicked on an unread message in a mailing-list-specific server-side folder and had Little Snitch alert me to MailMate trying to retrieve a web bug from salesforce.com. I can see two possible ways that this may have escaped your ill-conceived attempts to nuance when to retrieve external references automatically:

  1. The message structure was complex:
     multipart/alternative text/plain multipart/mixed text/html text/html <--- This was a forwarded message with the web bug text/html

  2. The message seemed to be marked as having been read before MailMate tried to retrieve the bug, so the message no longer was unread and was not in any Inbox. It also was not marked as spam because it was not spam, but it included a quoted copy of someone else's spam.

  As I've said earlier in this ticket, the problem here is in the design, not just the implementation. If you intend to continue to try to take a nuanced approach to this issue that sometimes can retrieve external components without the user explicitly asking for them, JUST SAY SO and I will never bug you again. I promise.

• You flagged this item as spam.
  

  Bill Cole March 6th, 2011 @ 09:10 PM

  formatting screwed up there. This time after using the Preview:

  multipart/alternative
       text/plain
       multipart/mixed
            text/html
            text/html   <--- This was a forwarded message with the web bug
            text/html
  

• 

  benny March 7th, 2011 @ 08:31 AM

  First, why it did not block the message (whether that is a an “ill-conceived” design or not): See the rules in the first comment in this ticket. Essentially, MailMate currently trusts most things outside the Inbox.

  As previously stated, I DO want to improve this. The current solution is a temporary attempt at satisfying users both like you and those who feel just as strongly that MailMate should not block images as often as it does.

  Now, we're in luck, because I was going to look at this and related issues today and hopefully that means a solution which is also going to satisfy you. If you have time then you are most welcome to write me a private email (use “Send Feedback...“ in the Help menu if you haven't switched mail application yet). You would then be able to comment on any changes before the next public update.

• 

  benny March 7th, 2011 @ 01:37 PM

  I'm working on it now, but I just realized there is a quick solution to always block external references. Go to the Terminal and paste the following (you should quit MailMate first):

  defaults write com.freron.MailMate MmBlockedMessagesQuery '$Msgs'
  

  It could be made more lenient if you like (I guess not) such as:

  defaults write com.freron.MailMate MmBlockedMessagesQuery '$Msgs.filter(#flags.flag !=[x] "$NotJunk")'
  

  (I haven't tested the second one.)

  And no, there is no documentation for the query “language”.

  The above method is already deprecated, but it'll work until the next update.