[Mailman-Developers] Re: [Mailman-cabal] Invitation to the CERT Vendor Meeting 2021 [General-7305] - mailman

[Mark Sapiro]

On 4/21/21 11:25 AM, Stephen J. Turnbull wrote:
> Hi,
> 
> There was recently a mail on the (closed) Mailman security list from
> the CERT Coordination Center which had this strange CC field:
> 
> CC: '@mail.python.org, c...@mail.python.org, e...@mail.python.org,
>   r...@mail.python.org, t...@mail.python.org, o...@mail.python.org,
>   r...@mail.python.org, d...@mail.python.org, i...@mail.python.org,
>   n...@mail.python.org, a...@mail.python.org, t...@mail.python.org,
>   e...@mail.python.org, c...@mail.python.org, "", "."@mail.python.org,
>   g...@mail.python.org
> 
> I guess those are "conformant" email addresses, but they seem unlikely
> to be mailboxes at python.org.  I'm not sure if these addresses were
> added by the generating software at CERT, some MTA, or Mailman.
> 
> Has anybody seen anything like this before?


My fault. There was an issue on mpo causing a shunted message
, and I installed a
quick but incorrect patch to fix it which caused this. The patch has
since been removed. I've got a correct fix, but am working on tests
before committing it.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
___
Mailman-Developers mailing list -- mailman-developers@python.org
To unsubscribe send an email to mailman-developers-le...@python.org
https://mail.python.org/mailman3/lists/mailman-developers.python.org/
Mailman FAQ: https://wiki.list.org/x/AgA3

Security Policy: https://wiki.list.org/x/QIA9

[Mailman-Developers] [Mailman-cabal] Invitation to the CERT Vendor Meeting 2021 [General-7305] - mailman

[Stephen J. Turnbull]

Hi,

There was recently a mail on the (closed) Mailman security list from
the CERT Coordination Center which had this strange CC field:

CC: '@mail.python.org, c...@mail.python.org, e...@mail.python.org,
r...@mail.python.org, t...@mail.python.org, o...@mail.python.org,
r...@mail.python.org, d...@mail.python.org, i...@mail.python.org,
n...@mail.python.org, a...@mail.python.org, t...@mail.python.org,
e...@mail.python.org, c...@mail.python.org, "", "."@mail.python.org,
g...@mail.python.org

I guess those are "conformant" email addresses, but they seem unlikely
to be mailboxes at python.org.  I'm not sure if these addresses were
added by the generating software at CERT, some MTA, or Mailman.

Has anybody seen anything like this before?

P.S. I hope I'm not spoiling this for any amateur sleuths who wanted
to figure it out for themselves, but yes, except for the apostrophe
and the empty address, those are the letters in "CERT Coordination
Center ", in order, with dupes eliminated.

P.P.S. It's about a conference, not a CVE.  Hakuna matata!

Steve

___
Mailman-Developers mailing list -- mailman-developers@python.org
To unsubscribe send an email to mailman-developers-le...@python.org
https://mail.python.org/mailman3/lists/mailman-developers.python.org/
Mailman FAQ: https://wiki.list.org/x/AgA3

Security Policy: https://wiki.list.org/x/QIA9

[Mailman-Developers] Re: [MM3-users] Long lines in mail composed by HyperKitty

[Stephen J. Turnbull]

Abhilash Raj writes:

 > Is this something new that you’ve noticed?

I've been noticing long-lines in format=fixed (ie, the default
setting) for a while, but hadn't paid attention to the sending
clients.  For some reason I was rooting around in the headers of this
particular message, and saw HyperKitty and that kinda tickled my RFC
wonk reflex. :-)

 > I think previously, Hyperkitty used to wrap lines at 90 characters
 > when displaying them in UI

UI shouldn't have anything to do with the message as formatted for the
wire, though.  I'm not seeing this in the UI, I'm seeing a message
*sent from the HyperKitty UI*, viewed in my usual Emacs-based MUA.

 > and then I think the replies would’ve been wrapped at 90 + “ >”
 > (2 chars) per line maximum. I may need to confirm this because we
 > don’t do anything else when sending the message or any recent
 > changes to that part of the code.
 > 
 > But recently, when adding support for rich text rendering, I think
 > I removed that 90 char wrap in the UI,

This shouldn't be related to my issue.

 > > I think that HyperKitty should format mail per RFC 3676 format=flowed
 > > https://tools.ietf.org/html/rfc3676#section-4.  However, I don't use
 > > "modern" (aka crappy HTML-oriented) clients, so I don't know whether
 > > they handle format=flowed properly.
 > 
 > Support for format=flowed is good in the web client (Fastmail) and Mac
 > client that I’ve been using.

Good!

 > Just to confirm this, but the way to implement that would be to add
 > format=flowed to the generated email’s content-type header and then 
 > add a CRLF after LINE_LENGTH octects, right?

No, basically the idea is to take a message formatted for fixed-length
lines, and allow the receiving client to reflow paragraphs as it wants
to.

The method is to add "format=flowed" to the generated MIME body's
content-type header field, and then append an ASCII space to the end
of each line that is part of a flowable paragraph.  Each paragraph
ends with a fixed line (no trailing space).

Preformatted tables and ASCII art are supported by simply not adding
the space.  Obviously that is not an easy thing to do for a plain
text message body source, but should be easy for Markdown source.

The rules for handling quoted material are non-trivial and not very
smart.  Eg, the quoting style where the writer's initials appear
before the ">" as in "sjt>" is not supported, and will be very ugly if
flowed.  See the RFC for that.
https://tools.ietf.org/html/rfc3676#section-4

I would expect that email.message supports generating format=flowed
message bodies, at least the simple case of a series of flowed
paragraphs, but I haven't checked.

 > We use EmailMessage[1] from Django[2], which is itself a wrapper over Message
 > class form standard library. I don’t know if the BytesGenerator supports
 > some sort of policy when serializing the body, but if not, I guess we can
 > handle breaking lines with CRLF before we pass it to Django.

That's helpful, thanks!  Yes, I suspect that we should do our own
rendering.

Steve

___
Mailman-Developers mailing list -- mailman-developers@python.org
To unsubscribe send an email to mailman-developers-le...@python.org
https://mail.python.org/mailman3/lists/mailman-developers.python.org/
Mailman FAQ: https://wiki.list.org/x/AgA3

Security Policy: https://wiki.list.org/x/QIA9