Does hyperkitty show JPEGs in line and what about attachments?
I run several MailMan 2.1 mailing lists and some subscribers are frustrated by the way pipermail deals with JPEGs that are embedded in the messages and also with how attachments are handled. Does hyperkitty in Mailman 3.1 do better on these issues.
Assuming this message gets archived, I am going to try embedding a small picture right here:
Hopefully that shows up in the archive. I won't add an attachment because the list may not allow it but I'm curious how those are handled.
Thanks
Jason
Jason Glazer, P.E., BEMP, GARD Analytics, 90.1 ECB chair, 209 chair Admin for onebuilding.org building performance mailing lists
On 11-Jul-17 12:54, Jason Glazer wrote:
I run several MailMan 2.1 mailing lists and some subscribers are frustrated by the way pipermail deals with JPEGs that are embedded in the messages and also with how attachments are handled. Does hyperkitty in Mailman 3.1 do better on these issues.
Assuming this message gets archived, I am going to try embedding a small picture right here:
Hopefully that shows up in the archive. I won't add an attachment because the list may not allow it but I'm curious how those are handled.
Thanks
Jason
Jason Glazer, P.E., BEMP, GARD Analytics, 90.1 ECB chair, 209 chair Admin for onebuilding.org building performance mailing lists
I know that this particular list is setup to strip HTML and only distribute text/plain.
I haven't gotten to HyperKitty configuration yet (a lot of plumbing yet to do for my environment), but I too am interested in having HTML mail archived & viewable as an HTML MUA would show it.
I pretty much gave up on the 2.1 archiver for the HTML lists. Instead, I subscribed a mailbox to the lists, and served it to the community read-only with IMAP. Dovecot handles private 'seen' flags for shared mailboxes, so this let people use their favorite e-mail client to browse the archive.
I'm hoping that I won't have to reconstruct this for my new environment...but it's an option.
Thanks for the suggestion on a shared IMAP mailbox.
Jason
On 7/11/2017 4:45 PM, tlhackque via Mailman-users wrote:
On 11-Jul-17 12:54, Jason Glazer wrote:
I run several MailMan 2.1 mailing lists and some subscribers are frustrated by the way pipermail deals with JPEGs that are embedded in the messages and also with how attachments are handled. Does hyperkitty in Mailman 3.1 do better on these issues. Assuming this message gets archived, I am going to try embedding a small picture right here: Hopefully that shows up in the archive. I won't add an attachment because the list may not allow it but I'm curious how those are handled. Thanks Jason-- Jason Glazer, P.E., BEMP, GARD Analytics, 90.1 ECB chair, 209 chair Admin for onebuilding.org building performance mailing lists
I know that this particular list is setup to strip HTML and only distribute text/plain.
I haven't gotten to HyperKitty configuration yet (a lot of plumbing yet to do for my environment), but I too am interested in having HTML mail archived & viewable as an HTML MUA would show it.
I pretty much gave up on the 2.1 archiver for the HTML lists. Instead, I subscribed a mailbox to the lists, and served it to the community read-only with IMAP. Dovecot handles private 'seen' flags for shared mailboxes, so this let people use their favorite e-mail client to browse the archive.
I'm hoping that I won't have to reconstruct this for my new environment...but it's an option.
Mailman-users mailing list mailman-users@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
-- Jason Glazer, P.E., BEMP, GARD Analytics, 90.1 ECB chair, 209 chair Admin for onebuilding.org building performance mailing lists
On 7/11/17 9:54 AM, Jason Glazer wrote:
Assuming this message gets archived, I am going to try embedding a small picture right here:
This list filters content aggressively. The original post "body" was text/html and the "inline" image was still a separate image/jpeg part (referenced in an IMG tag in the HTML. Content filtering removed the image/jpeg part and converted the HTML to plain text using lynx.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
This list filters content aggressively. The original post "body" was text/html and the "inline" image was still a separate image/jpeg part (referenced in an IMG tag in the HTML. Content filtering removed the image/jpeg part and converted the HTML to plain text using lynx.
I guess the test really didn't end up proving anything.
Does anyone know if Hyperkitty can be configured to allow for inline images to be maintained so that an HTML file looks like a normal HTML message?
Also, can attachments to a message under Hyperkitty preserve their name rather than being "scrubbed" into "attachment-*.*" files?
-- Jason Glazer, P.E., BEMP, GARD Analytics, 90.1 ECB chair, 209 chair Admin for onebuilding.org building performance mailing lists
On 07/12/2017 04:47 AM, Jason Glazer wrote:
Does anyone know if Hyperkitty can be configured to allow for inline images to be maintained so that an HTML file looks like a normal HTML message?
Also, can attachments to a message under Hyperkitty preserve their name rather than being "scrubbed" into "attachment-*.*" files?
The answer to some of this is at <https://lists.mailman3.org/archives/list/test@mailman3.org/message/N3XVN3DCEDBK6GAXJEVHCN6JKEZ7VAVB/>.
One question unanswered by that post is what happens with an inline image in an HTML message body. In the original message, the image is referenced by an IMG tag with "src=" pointing to the image MIME part. Since this structure is not maintained in HyperKitty, inline images probably don't work.
Also, with respect to Mailman 2.1, if you want the scrubber to preserve file names and extensions, set the following in mm_cfg.py
SCRUBBER_DONT_USE_ATTACHMENT_FILENAME = False SCRUBBER_USE_ATTACHMENT_FILENAME_EXTENSION = True
and if you want scrubbed HTML to not be HTML escaped so it renders rather than looking like raw html, set
ARCHIVE_HTML_SANITIZER = 3
but note this comment from Defaults.py
# 3 - Remove text/html as attachments but don't HTML-escape them. Note: this # is very dangerous because it essentially means anybody can send an HTML # email to your site containing evil JavaScript or web bugs, or other # nasty things, and folks viewing your archives will be susceptible. You # should only consider this option if you do heavy moderation of your list # postings.
This is an issue with HyperKitty as it appears this is what HyperKitty does and there's no way to turn it off.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark
Thanks for the link to the test archive. That and your information has clarified things a lot.
Jason
On 7/12/2017 11:39 AM, Mark Sapiro wrote:
On 07/12/2017 04:47 AM, Jason Glazer wrote:
Does anyone know if Hyperkitty can be configured to allow for inline images to be maintained so that an HTML file looks like a normal HTML message?
Also, can attachments to a message under Hyperkitty preserve their name rather than being "scrubbed" into "attachment-*.*" files?
The answer to some of this is at <https://lists.mailman3.org/archives/list/test@mailman3.org/message/N3XVN3DCEDBK6GAXJEVHCN6JKEZ7VAVB/>.
One question unanswered by that post is what happens with an inline image in an HTML message body. In the original message, the image is referenced by an IMG tag with "src=" pointing to the image MIME part. Since this structure is not maintained in HyperKitty, inline images probably don't work.
Also, with respect to Mailman 2.1, if you want the scrubber to preserve file names and extensions, set the following in mm_cfg.py
SCRUBBER_DONT_USE_ATTACHMENT_FILENAME = False SCRUBBER_USE_ATTACHMENT_FILENAME_EXTENSION = True
and if you want scrubbed HTML to not be HTML escaped so it renders rather than looking like raw html, set
ARCHIVE_HTML_SANITIZER = 3
but note this comment from Defaults.py
# 3 - Remove text/html as attachments but don't HTML-escape them. Note: this # is very dangerous because it essentially means anybody can send an HTML # email to your site containing evil JavaScript or web bugs, or other # nasty things, and folks viewing your archives will be susceptible. You # should only consider this option if you do heavy moderation of your list # postings.
This is an issue with HyperKitty as it appears this is what HyperKitty does and there's no way to turn it off.
-- Jason Glazer, P.E., BEMP, GARD Analytics, 90.1 ECB chair, 209 chair Admin for onebuilding.org building performance mailing lists
On 12-Jul-17 12:39, Mark Sapiro wrote:
Also, with respect to Mailman 2.1, if you want the scrubber to preserve file names and extensions, set the following in mm_cfg.py
SCRUBBER_DONT_USE_ATTACHMENT_FILENAME = False SCRUBBER_USE_ATTACHMENT_FILENAME_EXTENSION = True
and if you want scrubbed HTML to not be HTML escaped so it renders rather than looking like raw html, set
ARCHIVE_HTML_SANITIZER = 3
but note this comment from Defaults.py
# 3 - Remove text/html as attachments but don't HTML-escape them. Note: this # is very dangerous because it essentially means anybody can send an HTML # email to your site containing evil JavaScript or web bugs, or other # nasty things, and folks viewing your archives will be susceptible. You # should only consider this option if you do heavy moderation of your list # postings.
This is an issue with HyperKitty as it appears this is what HyperKitty does and there's no way to turn it off.
This warning seems a bit dated, though it's not completely wrong. It comes from the days when HTML was new, browsers were fragile, and javascript treated with suspicion. And virus/spam scanners for email were non-existent.
Today, it's a very rare website that doesn't rely on javascript (Postorious and Hyperkitty use JS). Browsers, while they still have bugs, are much more defensive. And there are plenty of truly evil sites that they have to defend against.
It is certainly true that archived e-mail can turn your site into an unknowing distributor of malware: FLASH bugs, documents with embedded buffer overflows, cross-site scripting and the other many ills of the day. Wikis deal with this frequently.
However, in these cases, your mailing list has distributed the same bits to your subscribers - a community that you probably care more about than a random visitor to your (open) archive.
I wouldn't run a list - public or private - where the traffic doesn't go through SPAM and virus filtering before Mailman sees it. (SpamAssassin and ClamAV are good open-source solutions.) And once you've done that (and Mailman 3's optional DMARC), most of these attacks are defanged/mitigated. This is essentially automated moderation - to a point.
Note that all the Djano authentication schemes packaged with Mailman (facebook, google, etc) rely on javascript and are sites littered with what the comment refers to as "webbugs" - Google Analytics, tracking cookies, browser fingerprinting, 0 size images (the original webbug). They make money (and have become mainstream) using technologies that were considered anti-social when that warning was written. (Personally, I still think of them as anti-social, but the public has chosen to pay for services with privacy...)
While some may elect to stick with the highly restrictive policies of "plain text only", this limits the information content and applicability of the the platform. Whether this is acceptable depends on the community that you serve. Mailman can be an effective mechanism to deliver rich media on a "push" basis. And that's "rich" by 1980 standards (bold, well-formatted tables, an attached agenda or document package); not even "rich" by today's (sleeping cat videos...).
I think that Mailman has to be able to handle today's rich media with a reasonable degree of safety and convenience. Including in the archives. I thought that was one of the goals for Mailman Version 3...
I also think that the advice quoted above should be modified to better reflect these realities. Mailman isn't the only tool available to protect users from evil content, and aggressively filtering to plaintext is a very blunt instrument. Including anti-spam, anti-virus, DNS blacklisting, DKIM/DMARC tests in the delivery pipeline (most of which can be/is done before Mailman touches a post) should be strongly recommended.
Checks for headers indicating checked-by local (anti-spam/anti-virus) agents should be available in the Mailman rulesets (and require some cooperation from the MTA to ensure that they can't be passed through from outside.)
There is nothing wrong with running a plain text only site, if it serves your community. But if Mailman wants to be relevant in today's environment, it has to adapt to rich content as more than an unwelcome guest. (As I have :0)
On Jul 13, 2017, at 05:37 AM, tlhackque via Mailman-users wrote:
There is nothing wrong with running a plain text only site, if it serves your community. But if Mailman wants to be relevant in today's environment, it has to adapt to rich content as more than an unwelcome guest. (As I have :0)
Mailman is used in a wide and diverse ecosystem, and while it was born from connecting musicians to their fans, historically it's seen widespread use for technical discussion forums. In those cases, plain text mostly dominates (except perhaps for the occasional screenshot, etc.).
But it's also used, and useful for, many other forums. I agree things have gotten both better (browsers are generally more secure) and worse (privacy is the currency we pay for access). Wherever possible Mailman should provide choice for users and operators to make their own decisions about things like what media to pass or filter, etc. However, Mailman can and should be opinionated about its defaults, especially because I strongly suspect that users who "just want a mailing list" far outweigh users who have the knowledge, time, and motivation to tweak every detail up and down the chain. And knowledgeable users will read an admonition like that with a grain of salt and still make the decisions that are right for them.
I think we've walked a relatively good line between these competing constraints.
Cheers, -Barry
participants (4)
-
Barry Warsaw -
Jason Glazer -
Mark Sapiro -
tlhackque