Better support for multipart/alternative? #587

mrzool · 2017-05-17T19:14:07Z

I'm new to mutt and would like to use it for all my emails. I have spent the last couple of days trying to set up a sensible environment, but I'm hitting my head against (several) walls.

The struggle started when I realized that sending emails in plain text is not viable anymore nowadays, because hard line breaks render the text hardly readable on small screens, and I don't want my emails to be ugly and hardly readable. There's a couple of suggestions as to how to work around this with the unlucky standard format=flowed (set text_flowed in mutt) and some ad-hoc setting in Vim (setlocal fo=aw). I soon realized that this doesn't work in several major email clients. Text looking fine in Gmail web interface looked terrible in Outlook. format=flowed is thus not a viable solution to this issue.

It appears that the only way to get nicely wrapped, responsive text in emails is (horrors) marking it up with HTML. So I wrote a macro to convert the body of the message in the 'compose' window to HTML and change the Content-Type to text/html just before sending — I use Pandoc, which has the nice side-effect of allowing me to use Markdown in my emails. So far so good, things are working and I'm happy. But what about email clients that are unable to display HTML? I don't want to give up plain text wholesale, I want my emails to be as accessible as possible.

The standard solution to this is to use Content-Type: multipart/alternative and embed two versions of the same text in the body, one in plain text and one in HTML, delimiting the regions through a string named boundary:

Content-Type: multipart/alternative; boundary="myboundary"

So I wrote a (rudimentary) shell script that takes the email body, converts it as needed, sets the various boundaries between regions, and outputs a new body readily formatted for multipart/alternative. I integrated the script into my mutt macro and did some testing.

Well, nothing works as expected.

I write an email containing the following:

First paragraph.

Second paragraph.

Third paragraph.

Then I close and drop into the 'Compose' window. I filter the body through my script with F and I get this back, as expected:

--myboundary
Content-Type: text/plain; charset=utf-8

First paragraph. 
 
Second paragraph. 
 
Third paragraph. 

--myboundary
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html code omitted>

--myboundary--

Then I hit ^T and change Content-Type to multipart/alternative. All looks good. I hit Enter to inspect the attachment. All looks good. I hit Q to go back to 'Compose'. Mutt changed the content type back to text/plain.

I change the content type again. This time I send the message without inspecting the attachment. Mutt sends the email. I receive it in Gmail with the expected content type, an empty noname attachment and an empty body.

I try again. This time I change content type before converting the body. Same behavior. Every time I inspect the attachment Mutt changes the content type back to text/plain. If I send the email, I get an empty body and an empty noname attachment.

Is this a bug? Expected behavior? How can I send a multipart/alternative message using Mutt? Is support for this content type lacking? Can it be improved?

The text was updated successfully, but these errors were encountered:

gahr · 2017-05-17T19:39:00Z

I don't see any native support for this, unfortunately. As a workaround, I would tried setting

my_hdr Content-Type: multipart/alternative; boundary="myboubdary"

in .muttrc.

I'm not at the keyboard now so I can't really test it.

mrzool · 2017-05-17T22:47:57Z

Thanks @gahr, I'll try that as soon as I'm back from a trip in about a week and get back to you.

guyzmo · 2017-05-18T10:02:53Z

this is actually a project I've been working on for some time, and wrote a tool to convert my outgoing mail in HTML once I hit send. But that was wrong.

Even though I did not try it, I think @gahr's suggestion won't work, because mutt is managing the multipart header for the attachments, and adding twice that header could lead to a 🔥

guyzmo · 2017-05-18T10:08:50Z

I tried doing several huge macro hacks to generate an HTML attachment out of the full text one (using pandoc, because, yes, pandoc is ♥) and that alone was painful (which is one of the reasons I wrote the Lua scripting extension).

And then converting the mail to multipart is still an issue I'm thinking about. The way I think would be a great UX would be to tag the parts we want to be the alternatives and mark them as such.

(PS: sorry, had the cat walk over my hands and the trackpad and close the issue… I mean he really did it 😼)

mrzool · 2017-05-25T16:39:33Z

Indeed @guyzmo, @gahr's suggestion doesn't work, that just adds a second header to the message, leaving the original text/plain header intact.

I honestly think this is a significant shortcoming of Mutt, and would love to see it addressed in some way. Since plain text email are no longer a sensible choice for many (our emails get read on a plethora of different devices), it would be great to have just a bit of added flexibility in this sense.

If I were able to at least set the headers myself without Mutt messing with it afterwards, then I could write my own script to format the body properly and handle various scenarios (multipart/alternative for simple messages, multipart/mixed with embedded multipart/alternative for messages with additional attachments). Of course, there are several MUAs out there which handle this natively and automatically, but I really want to use Mutt :)

Any feedback on this?

guyzmo · 2017-05-25T17:50:32Z

actually, the multipart/alternative has been a huge troll 15 years ago, and I don't remember all the details, just that a huge part of the community was, then, against that. There's a standard way of overcoming this, though, it's to use the text_flowed setting which is supported by Mail.app or Gmail.

Whether doing the alternative support as a script or as a patch will really depend on how much change and how complex that will be (basically, if to add multipart/alternative support, one shall only expose structs and functions, that'd be a good way to go, if actually patching is needed… then it's not).

mrzool · 2017-05-26T22:02:38Z

If text_flowed were a reliable way to fix this I'd be very happy to settle for plain text emails without a second thought...sadly it's not, as I mentioned above. Proper implementation of this standard seems to be arduous, many major clients don't support it. That's why I'm looking into alternatives.

Yes, I've sensed hostility to supporting multipart/alternative in some old discussions on the matter, but no substantial argument was given against it as far as I can recall, other than "HTML in emails is bad and we shouldn't encourage its use". The thing is, 15 years after, HTML emails are everywhere, used by everyone, universally supported, guaranteed to be properly displayed by every client on every device, and solve all the problems I have with plain text emails.

At the end of the day it all boils down to this: In the current state, an email sent by Mutt has 100% chance to look like crap on a phone. Let that sink in.

In 2017, if there's a new trick an old dog needs to be taught, that's proper support of current accessibility standards, or at least enough flexibility to let users compensate for the lack thereof.

guyzmo · 2017-05-26T22:40:23Z

Sure, I share your frustration about this, and I'm saddened to see that HTML mail is everywhere, and that we get mandrillapp.com (or the others alike) links in not only newsletters but anybody's mail, with those 1px image just to track when you're opening the mail. And then you've got all those firms that specialise in 'e-mail design'. Unreadable, ugly and tracking is the new standard, and that's sickening ¯_(ツ)_/¯

So, in the end, let's focus on how/where to solve this. I'm going to have a look at that when I'll have the time to, if you want as well, you're welcome to do so! You can also join the IRC channel #neomutt on freenode 😉 It's likely to be a non-trivial change, and finding the simplest, less painful, yet elegant way to implement this won't be easy.

In terms of UX, what I've said is that we need to keep it simple, in the compose view, tag two attachments, and hit some tag-makealternative function with a binding, to make them multipart/alternative. Then a simple visual queue in the listing to show the "default' part, and the alternatives.

Then with a bit of macro magic (or scripting) you can automize the steps of select the body part, convert it as html into another part, select them both, make them alternatives, with the text/plain as default, and eventually send it.

mrzool · 2017-05-30T14:20:38Z

I apologize for the late reply, I've been busy after coming back home. I share your aversion to HTML email and its misuse, especially when plain text email would do just fine. But I have tried long and hard to get acceptable results using plain text emails (hell, I use plain text for everything) and things simply don't work as they should. The specifications are too old (hard line breaks instead of letting the receiving client deal with the wrapping), standards to work around their shortcomings (format=flowed) are ill-supported. If the the price to have a sane and consistent behavior across all clients and devices is to send out HTML, so be it! I'm not ideologically against it and I don't see anything inherently wrong with it if one doesn't start misusing it.

What surprises me is the lack of reactions and discussion around the topic. Am I the only one with this issue? Do people actually use Mutt as their main MUA, knowing that their email might come horribly scrambled to the receiver? Are folks fine with that? I would never trust Mutt in its current state to send out a job application or any important email.

I'd love to look into this, @guyzmo, but I'm not a C programmer nor an email expert, just a humble user trying to send some emails. I do thank you profusely for hearing me out in the first place, though!

somini · 2017-05-30T20:15:47Z

I use mutt as my main MUA, but I don't send that much mail and mostly keep it short. I'm not against writing markdown and using pandoc to convert it to html, but it's not an easy task to mangle the current mutt into doing this.
Now with the Lua API it should be possible to do this in a non insane way, but it's at least a weekend of work to get a prototype going. We are all volunteers, that's why the default response is helping the users help themselves.

gahr · 2017-05-30T21:24:06Z

I don't think talking mutt into producing html emails is a solution for this problem. It would just hide the issue for MUAs that do support html but do not handle the flowed format specs of MIME.

Edit: inadvertently pushed Comment too early, continuing below:

Doing so would just turn the problem the other way around: MUAs supporting HTML would display your email just fine, while text-only MUAs that do support format=flowed will display crap.

Just thinking.. is this really a mutt issue?

guyzmo · 2017-05-31T06:37:11Z

Well, currently my own work around is that when I send mails to people I know will read my mail on crappy UIs (phones, outlook…), I join (J) the paragraphs into long lines. Then it's ugly for me, but fine for them. No need for flowed or anything.

When I'm talking with people that have a proper MUA, or should know how to configure (and chose) a decent MUA, then I do proper line breaks. And formatting.

My goal is that I like to enforce presentation in my mails, doing some simple ASCII art or lines alignment, and people tend to read their mail with a variable width font. My personal take on using multipart/alternative would be to enforce a stylesheet that would force people to read my mail the way I designed it, and with a proper fixed-width font… while keeping the text/plain alternative clean and sane.

So is it a mutt issue? I don't think so, as it's been discarded as being an issue for a couple of decades. But it's definitely a feature request, which I hope we'll be able to implement with minimal changes to mutt.

somini · 2017-05-31T08:30:21Z

This is not really producing HTML email, the feature request is authoring multipart/alternative emails. Mutt can read them just fine, but you can't create them.

gahr · 2017-05-31T08:43:56Z

If this boils down to having mutt respect and work with what I suggested earlier, namely
my_hdr Content-Type: multipart/alternative; boundary="myboubdary"
I'm all for it :) Anything further than that (automatic format conversion using pandoc, automatic generation of text/plain from html, ...) is out of scope, IMHO.

mrzool · 2017-05-31T08:56:24Z

@somini:

I'm not against writing markdown and using pandoc to convert it to html, but it's not an easy task to mangle the current mutt into doing this.

Actually I managed to get this working with a fairly simple macro:

macro compose \; "F pandoc --smart -s -f markdown -t html<enter>y^T^Utext/html; charset=utf-8<enter>"

Problems arise only when turning this up a notch and trying to compose an email which has both text/plain and text/html alternatives and multipart/alternative as content type.

@gahr

It would just hide the issue for MUAs that do support html but do not handle the flowed format specs of MIME.

Again, producing HTML emails it's not the issue, that works just fine with the Pandoc macro.

MUAs supporting HTML would display your email just fine, while text-only MUAs that do support format=flowed will display crap.

That's exactly what multipart/alternative would solve! Sorry if the point got lost in my overly verbose comments.

As a side note, I had noticed that Mutt already has some awareness of multipart/alternative. When trying to send a message with multipart/alternative set, but no boundary, Mutt gives this error:

No boundary parameter found!

Not sure what to make of that, but it gave me hope when I was desperately trying to get this working.

mrzool · 2017-05-31T09:08:56Z

@gahr

Anything further than that (automatic format conversion using pandoc, automatic generation of text/plain from html, ...) is out of scope, IMHO.

I'm not suggesting that this ability should be built into Mutt, far from it! Just that a user should be able to filter an attachment using his/her own scripts (already possible, it's a working feature) and set the desired content/type (which is a simple string of text). That's just interface scriptability, which is one of the main points of using Mutt.

gahr · 2017-05-31T09:26:31Z

I am able to force the content type using the, surprise, content_type setting:

:set content_type="multipart/alternative; boundary=\"__bound__\""

But so far I haven't been able to actually produce and send a multipart email. Might be a good start, though.

mrzool · 2017-05-31T09:39:17Z

Yep, that's exactly the issue. Filtering attachments through scripts works, setting a multipart/alternative content type works (though Mutt changes it back to text/plain after you view the attachment with <Enter>...bug?), yet the email arrives empty and with a noname attachment containing nothing.

Content-Type: multipart/alternative; boundary="myboundary"
Content-Disposition: inline
In-Reply-To: <CA+OhsQKsbpSbC8KEWYGfE_1C+Mu=aKFK9tx80sqd=4XQ_REnzg@mail.gmail.com>
User-Agent: Mutt/1.8.2 (2017-04-18)

--myboundary--

Seems like this is very close to working, but something interferes while sending.

gahr · 2017-05-31T09:44:44Z

Alright, I now understand the issue as a whole. Sorry if it took a few iterations ;)

gahr · 2017-05-31T11:13:34Z

Ok, so this is how you send a multipart email with mutt:

prepare your parts (text, html) as separate files - you are going to add those as attachments;
set your content_type to multipart/alternative - you don't need to specify a boundary;
compose a new email - the body doesn't matter;
add the files that you prepared in step 1. as attachments
modify the Content-Type of each attachment as needed (highlight the attachment, then exec edit-type or Ctrl-T) - if you named your files with proper extensions, mutt should be able to figure it out itself
remove attachment 1, that is, the main body
send

Edit: not quite. This results in a multipart/mixed.

guyzmo · 2017-05-31T11:19:12Z

to be clear, @gahr, the html thing not being part of mutt is what I'm advocating, and is one of the reasons I wanted Lua scripting (it's possible using macros, but my experiments made me endup doing a way too complex macro for that), and I've started doing it. We all agree that we don't want to see anything related to HTML within Mutt. Never. It shall happen in filters, scripts, anywhere else.

About the multipart, what needs to happen is simply have the possibility to select (T) two or more attachments in compose screen, and mark them as multipart/alternative, and done. I think hacking with the :set content_type of the mail is wrong, because you might want to have a mail structure such as:

    multipart/mixed (mail)
        multipart/alternative (attachment #1)
            text/plain (#1.1)
            text/html (#1.2)
            text/calendar (#1.3)
        application/ics (attachment #2)
        application/pdf (attachment #3)
        image/jpeg (attachment #4)

you might also have a visual feedback to see when, and which attachments are part of an alternative, maybe alike the attachment view for multipart alternative:

 I     1 <no description>           [multipa/alternativ, 7bit, 61K] 
 I     2 ├─><no description>      [text/plain, base64, utf-8, 4.7K] 
 I     3 ├─><no description>        [text/html, quoted, utf-8, 54K] 
 I     4 └─><no description>     [text/calendar, 7bit, utf-8, 1.7K] 
 A     5 invite.ics                     [applica/ics, base64, 2.3K]

I guess that's a long shot and maybe we should split the work in small increments toward proper compose support of the multipart/alternative.

guyzmo · 2017-05-31T11:20:52Z

Ok, so this is how you send a multipart email with mutt:

ok, so that's a start, we just need to make it not a huge absurd hack (editing parts from elsewhere, removing main attachments, changing the whole content-type etc.).

gahr · 2017-05-31T11:27:58Z

I just found this. Has anybody seen / tried it?

gahr · 2017-05-31T11:38:27Z

@guyzmo everything you said is correct. We might want to try to import that patch and see if it's sufficient.

guyzmo · 2017-05-31T13:09:51Z

OMG ♥♥♥ gotta try that 😀

mrzool · 2017-05-31T13:16:12Z

@gahr We're definitely getting there, but, as you noted, using your method the email gets sent as multipart/mixed, a boundary gets inserted automatically by Mutt, but there's no nested multipart/alternative, so both the attachments end up displayed in the email body one after the other (also, one needs to change disposition of the attachments from attachment to inline with ^D before sending, otherwise both files get sent as external attachments).

I rejoice, however, in finding confirmation that a support for multipart messages is already present in Mutt! The automatic insertion of a boundary is the definitive proof. Maybe implementing better support will not be so hard after all? All the pieces seem to be already there.

mrzool · 2017-06-07T11:53:43Z

Any luck with that patch @guyzmo?

mrzool · 2017-11-17T11:51:00Z

@libBletchley

That's why I suggested text/enriched. It gives the effect of format=flowed without actually using that parameter.

That sounds really interesting and might be a better solution than quoted-printable. I will look into it, many thanks for bringing this up!

This is still WIP, mutt segfaults right after sending the email. This is the work of @oblitium, based on this unattributed patch: https://github.com/altercation/arch-packages/blob/master/mutt-dgc-hg/dgc.groupalts References #587

@somini

This work is based on commit 5b4f7a1 from @somini and was discussed at <neomutt#587>. As of now, one can tag entries in the compose menu and use <group-alternatives> to group those entries into one. If all the entries are tagged (including the fundamental part), then the email become a multipart/alternative one, otherwise it becomes a multipart/mixed one. There is some weird things to be noted, though: when postponning a multipart/alternative mail and then recall it, those entries get splitted up. This does not occurred for multipart/mixed mails.

This is still WIP, mutt segfaults right after sending the email. This is the work of @oblitium, based on this unattributed patch: https://github.com/altercation/arch-packages/blob/master/mutt-dgc-hg/dgc.groupalts References #587

@somini

This work is based on commit 5b4f7a1 from @somini and was discussed at <#587>. As of now, one can tag entries in the compose menu and use <group-alternatives> to group those entries into one. If all the entries are tagged (including the fundamental part), then the email become a multipart/alternative one, otherwise it becomes a multipart/mixed one. There is some weird things to be noted, though: when postponing a multipart/alternative mail and then recall it, those entries get split up. This does not occurred for multipart/mixed mails.

This is still WIP, mutt segfaults right after sending the email. This is the work of @oblitium, based on this unattributed patch: https://github.com/altercation/arch-packages/blob/master/mutt-dgc-hg/dgc.groupalts References #587

@somini

This work is based on commit 5b4f7a1 from @somini and was discussed at <#587>. As of now, one can tag entries in the compose menu and use <group-alternatives> to group those entries into one. If all the entries are tagged (including the fundamental part), then the email become a multipart/alternative one, otherwise it becomes a multipart/mixed one. There is some weird things to be noted, though: when postponing a multipart/alternative mail and then recall it, those entries get split up. This does not occurred for multipart/mixed mails.

This is still WIP, mutt segfaults right after sending the email. This is the work of @oblitium, based on this unattributed patch: https://github.com/altercation/arch-packages/blob/master/mutt-dgc-hg/dgc.groupalts References #587

@somini

This work is based on commit 5b4f7a1 from @somini and was discussed at <#587>. As of now, one can tag entries in the compose menu and use <group-alternatives> to group those entries into one. If all the entries are tagged (including the fundamental part), then the email become a multipart/alternative one, otherwise it becomes a multipart/mixed one. There is some weird things to be noted, though: when postponing a multipart/alternative mail and then recall it, those entries get split up. This does not occurred for multipart/mixed mails.

@oblitum

This is still WIP, mutt segfaults right after sending the email. This is the work of @oblitum. References #587

@somini

This work is based on commit 5b4f7a1 from @somini and was discussed at <#587>. As of now, one can tag entries in the compose menu and use <group-alternatives> to group those entries into one. If all the entries are tagged (including the fundamental part), then the email become a multipart/alternative one, otherwise it becomes a multipart/mixed one. There is some weird things to be noted, though: when postponing a multipart/alternative mail and then recall it, those entries get split up. This does not occurred for multipart/mixed mails.

@oblitum

This is still WIP, mutt segfaults right after sending the email. This is the work of @oblitum. References #587

@somini

This work is based on commit 5b4f7a1 from @somini and was discussed at <#587>. As of now, one can tag entries in the compose menu and use <group-alternatives> to group those entries into one. If all the entries are tagged (including the fundamental part), then the email become a multipart/alternative one, otherwise it becomes a multipart/mixed one. There is some weird things to be noted, though: when postponing a multipart/alternative mail and then recall it, those entries get split up. This does not occurred for multipart/mixed mails.

@oblitum

This is still WIP, mutt segfaults right after sending the email. This is the work of @oblitum. References #587

@somini

This work is based on commit 5b4f7a1 from @somini and was discussed at <#587>. As of now, one can tag entries in the compose menu and use <group-alternatives> to group those entries into one. If all the entries are tagged (including the fundamental part), then the email become a multipart/alternative one, otherwise it becomes a multipart/mixed one. There is some weird things to be noted, though: when postponing a multipart/alternative mail and then recall it, those entries get split up. This does not occurred for multipart/mixed mails.

flatcap · 2018-05-03T18:20:43Z

Closed by 08f6862

archenemies · 2019-01-12T23:02:09Z

It looks like a lot of work has been done on this issue, can someone point the discussion to the recommended way of using the new feature (e.g. to send a Gmail-style email with HTML attached?). Thank you.

scy · 2020-01-27T14:25:14Z

It looks like a lot of work has been done on this issue, can someone point the discussion to the recommended way of using the new feature (e.g. to send a Gmail-style email with HTML attached?).

That request is now more than a year old, but for anyone who may find this issue in the future, here’s the documentation: https://neomutt.org/guide/mimesupport#5-%C2%A0mime-multipart-alternative

It also contains an example macro to pipe a text/plain attachment through Pandoc and bundle the plain text together with the resulting HTML:

macro compose K "| pandoc -o /tmp/neomutt-alternative.html<enter> \
    <attach-file>/tmp/neomutt-alternative.html<enter> \
    <tag-entry><previous-entry><tag-entry><group-alternatives>"

TornaxO7 · 2021-03-28T21:55:50Z

Hm I still don't really understand how to read an multiple/alternative mail. Can anyone explain me that a little bit more detailed?
Because if I try to open a multiple/alternative file (as an attachment), than I can just see the whole file as an html file but without any formats. Just it's "source code".

TornaxO7 · 2021-03-28T22:22:52Z

Ok, I created a little own solution for opening multiple/alternative files:
Add the following into your ~/.mailcap:

text/html; cp %s /tmp/neomutt_alternative.html && sed -i "1s/^/<!DOCTYPE html> <html>/" /tmp/neomutt_alternative.html && echo "</html>" >> /tmp/neomutt_alternative.html && chromium /tmp/neomutt_alternative.html

This will add the needed tags for a completed html file and it will open the modified file in chromium.

guyzmo closed this as completed May 18, 2017

guyzmo reopened this May 18, 2017

ghost added the type:enhancement Feature Request label Jun 7, 2017

walkerlala mentioned this issue Mar 11, 2018

support for multipart/alternative and multipart/mixed #1094

Closed

flatcap pushed a commit that referenced this issue Apr 25, 2018

Initial support for multipart/alternative

754d745

This is still WIP, mutt segfaults right after sending the email. This is the work of @oblitum. References #587

flatcap pushed a commit that referenced this issue Apr 25, 2018

Initial support for multipart/alternative

747e57a

This is still WIP, mutt segfaults right after sending the email. This is the work of @oblitum. References #587

flatcap pushed a commit that referenced this issue May 2, 2018

Initial support for multipart/alternative

b7dc51f

This is still WIP, mutt segfaults right after sending the email. This is the work of @oblitum. References #587

flatcap closed this as completed May 3, 2018

archenemies mentioned this issue Jan 15, 2019

Filtering whole message in Compose #1542

Closed

Better support for multipart/alternative? #587

Better support for multipart/alternative? #587

mrzool commented May 17, 2017 •

edited

gahr commented May 17, 2017

mrzool commented May 17, 2017

guyzmo commented May 18, 2017

guyzmo commented May 18, 2017

mrzool commented May 25, 2017

guyzmo commented May 25, 2017

mrzool commented May 26, 2017

guyzmo commented May 26, 2017

mrzool commented May 30, 2017 •

edited

somini commented May 30, 2017

gahr commented May 30, 2017 •

edited

guyzmo commented May 31, 2017

somini commented May 31, 2017

gahr commented May 31, 2017

mrzool commented May 31, 2017

mrzool commented May 31, 2017

gahr commented May 31, 2017

mrzool commented May 31, 2017

gahr commented May 31, 2017

gahr commented May 31, 2017 •

edited

guyzmo commented May 31, 2017

guyzmo commented May 31, 2017

gahr commented May 31, 2017

gahr commented May 31, 2017

guyzmo commented May 31, 2017

mrzool commented May 31, 2017

mrzool commented Jun 7, 2017

mrzool commented Nov 17, 2017

flatcap commented May 3, 2018

archenemies commented Jan 12, 2019

scy commented Jan 27, 2020

TornaxO7 commented Mar 28, 2021

TornaxO7 commented Mar 28, 2021

Better support for multipart/alternative? #587

Better support for multipart/alternative? #587

Comments

mrzool commented May 17, 2017 • edited

gahr commented May 17, 2017

mrzool commented May 17, 2017

guyzmo commented May 18, 2017

guyzmo commented May 18, 2017

mrzool commented May 25, 2017

guyzmo commented May 25, 2017

mrzool commented May 26, 2017

guyzmo commented May 26, 2017

mrzool commented May 30, 2017 • edited

somini commented May 30, 2017

gahr commented May 30, 2017 • edited

guyzmo commented May 31, 2017

somini commented May 31, 2017

gahr commented May 31, 2017

mrzool commented May 31, 2017

mrzool commented May 31, 2017

gahr commented May 31, 2017

mrzool commented May 31, 2017

gahr commented May 31, 2017

gahr commented May 31, 2017 • edited

guyzmo commented May 31, 2017

guyzmo commented May 31, 2017

gahr commented May 31, 2017

gahr commented May 31, 2017

guyzmo commented May 31, 2017

mrzool commented May 31, 2017

mrzool commented Jun 7, 2017

mrzool commented Nov 17, 2017

flatcap commented May 3, 2018

archenemies commented Jan 12, 2019

scy commented Jan 27, 2020

TornaxO7 commented Mar 28, 2021

TornaxO7 commented Mar 28, 2021

mrzool commented May 17, 2017 •

edited

mrzool commented May 30, 2017 •

edited

gahr commented May 30, 2017 •

edited

gahr commented May 31, 2017 •

edited