Mark Sapiro added the comment:
Upon further research I realized this is related to
https://bugs.python.org/issue30681 and that while there are no message.defects
the Date: header does have the InvalidDateDefect and its datetime attribute is
None so I consider this resolved
New submission from Mark Sapiro :
Here is an interactive Python session
```
Python 3.10.1 (main, Dec 7 2021, 15:44:39) [GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from email import message
Mark Sapiro added the comment:
The mailman-us...@python.org list received a post with the From: header
containing a Hebrew display name RFC 2047 encoded with the iso-8859-8-i charset
which threw a LookupError: unknown encoding: iso-8859-8-i exception in
processing and shunted the message
New submission from Mark Sapiro :
iso-8859-6-i, iso-8859-6-e, iso-8859-8-i and iso-8859-8-i are all IANA
recognized character sets per
https://www.iana.org/assignments/character-sets/character-sets.xhtml. These are
all unrecognized by codecs.lookup().
--
components: Library (Lib
Change by Mark Sapiro :
--
versions: +Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue44560>
___
___
Python-bugs-list mailin
Mark Sapiro added the comment:
Thank you for the explanation which I understand and accept. I also fully (or
maybe not quite fully) understand the use of square brackets to indicate
optional arguments. It's just that in the context of the table at
https://docs.python.org/3/li
New submission from Mark Sapiro :
In several places in the documentation including:
```
grep -rn 'pop.\[i\]'
Lib/pydoc_data/topics.py:13184: '| "s.pop([i])" |
retrieves the item at *i* '
Lib/pydoc_data/topics.py:13647:
New submission from Mark Sapiro :
With Policy = email.policy.default, there are handlers for get_content() only
for content types 'text', 'audio', 'image', 'video', 'application',
'message/rfc822', 'message/external-body'
Mark Sapiro added the comment:
I work around it with
```
class Message(email.message.Message):
def as_string(self):
# Work around for https://bugs.python.org/issue27321 and
# https://bugs.python.org/issue32330.
try:
value
Change by Mark Sapiro :
--
pull_requests: +19786
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/20542
___
Python tracker
<https://bugs.python.org/issu
Mark Sapiro added the comment:
With the fix in PR 20038, committed at
https://github.com/python/cpython/commit/6f2f475d5a2cd7675dce844f3af436ba919ef92b
it is no longer possible to set_content(''). Attempts to do so produce the
following
```
File
"/var/MM/3/hk_39/hyper
Mark Sapiro added the comment:
I've researched this further, and I know how this happens. The original message
contains a text/html part (in my case, the only part) which contains a base64
or quoted-printable body which when decoded contains non-ascii. It is parsed
correct
Mark Sapiro added the comment:
Other Mailman3 installations are also encountering this issue. See
https://lists.mailman3.org/archives/list/mailman-us...@mailman3.org/message/VQZORIDL5PNQ4W33KIMVTFTANSGZD46S/
--
___
Python tracker
<ht
Mark Sapiro added the comment:
This came about because of an actual situation in a Mailman 3 installation. I
can't say for sure what the actual original message looked like, but it was
received by Mailman's LMTP server and parsed with email.message_from_bytes(),
so it clearly wasn
Change by Mark Sapiro :
--
pull_requests: +17467
pull_request: https://github.com/python/cpython/pull/18074
___
Python tracker
<https://bugs.python.org/issue27
Change by Mark Sapiro :
--
keywords: +patch
pull_requests: +17453
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/18059
___
Python tracker
<https://bugs.python.org/issu
Change by Mark Sapiro :
--
versions: +Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue32330>
___
___
Python-bugs-list mailin
Change by Mark Sapiro :
--
versions: +Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue39384>
___
___
Python-bugs-list mailing list
Unsub
New submission from Mark Sapiro :
This is similar to https://bugs.python.org/issue32330 but is the opposite
behavior. In that issue, the message couldn't be flattened as a string but
could be flattened as bytes. Here, the message can be flattened as a string but
can't be flattene
New submission from Mark Sapiro :
This is really due to an nntp server bug, but here's the scenerio.
A connection is opened to the server.
An article is posted via the connection's post() method.
The server responds to the article data with
240 Article posted
but due to the serv
Mark Sapiro added the comment:
I do intend to submit a PR. I haven't yet worked it out though.
--
___
Python tracker
<https://bugs.python.org/is
New submission from Mark Sapiro :
The code in the attached parse_bug.py file when run with Python 3.5, 3.6 or 3.7
throws AttributeError with this traceback:
```
Traceback (most recent call last):
File "parse_bug.py", line 9, in
""")
File "/usr/local
Mark Sapiro added the comment:
I agree that my example with an @ in the 'display name', although actually seen
in the wild, is non-compliant, and that the behavior of parseaddr() in this
case is not a bug.
Sorry for the noise.
--
Mark Sapiro added the comment:
The issue is illustrated much more simply as follows:
email.utils.parseaddr('John Doe j...@example.com ')
returns
('', 'John Doe j...@example.com')
whereas it should return
('John Doe j...@example.com', 'ot...@e
Mark Sapiro added the comment:
> I do wonder where you are using the string version of messages :)
Probably some places where we could use bytes, but one of the problem areas is
where we save the content of a message held for moderat
Mark Sapiro added the comment:
Yes. I think errors=replace is a good solution. In Mailman, we have our own
mailman.email.message.Message class which is a subclass of
email.message.Message and what we do to work around this and issue27321 is
override as_string() with:
def as_string(self
New submission from Mark Sapiro :
This is related to https://bugs.python.org/issue27321 but a different exception
is thrown for a different reason. This is caused by a defective spam message. I
don't actually have the offending message from the wild, but the attached
bad_email_
Change by Mark Sapiro :
--
nosy: +msapiro
___
Python tracker
<https://bugs.python.org/issue32144>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Sapiro added the comment:
It looks like Johannes beat me to it. Thanks for that, but see my comments in
the diff at
https://github.com/kyrias/cpython/commit/a986a8274a522c73d87360da6930e632a3eb4ebb
--
___
Python tracker
<h
Mark Sapiro added the comment:
I considered look before you leap, but I decided since we're munging the
headers anyway, preserving their order is not that critical, but the patch is
easy enough. I'll work on that and a test.
--
___
Pyth
Mark Sapiro added the comment:
One additional observation. The original message contained no
Content-Transfer-Encoding header even though the message body was raw koi8-r
characters. Adding
Content-Transfer-Encoding: 8bit
to the message headers avoids the issue, but that is not a practical
New submission from Mark Sapiro:
The attached file, bad_email, can be parsed via
msg = email.message_from_binary_file(open('bad_email', 'rb'))
but then msg.as_string() prodices the following:
Traceback (most recent call last):
File "", line 1, in
File "
Mark Sapiro added the comment:
Added Python 2.7 to versions:
--
versions: +Python 2.7
___
Python tracker
<http://bugs.python.org/issue26686>
___
___
Python-bug
New submission from Mark Sapiro:
Given an admittedly defective (the folded Content-Type: isn't indented) message
part with the following headers/body
---
Content-Disposition: inline; filename="04EBD_._A546BB.zip"
Content-Type: application/x-ra
Mark Sapiro added the comment:
> parsing 'merwok'
> expected ('merwok', '')
> got ('', 'merwok')
I think ('', 'merwok') is the correct result. I think most if not all MUAs/MTAs
will interpret an address wit
Mark Sapiro added the comment:
I'm not completely sure about this, but here's my thoughts. In the
scenarios I've seen, the 421 reply/disconnect only occurs in response to
a RCPT which has an invalid address and follows several prior refused
RCPTs. In this case, I think the prop
New submission from Mark Sapiro :
RFC821 upon which smtplib was originally based does not define a 421
status code and implies the server should only disconnect in response to
a QUIT command.
Subsequent extensions in RFC2821 (and now RFC5321) define situations
under which the server may return
New submission from Mark Sapiro :
The message method get_params() and the related get_param() and
get_filename() do not properly decode an RFC 2231 encoded parameter such
as the following:
Content-Disposition: inline;
filename*0="Re: [Mailman-Users] Messages shunted with \"
Mark Sapiro added the comment:
Thank you for adding the redirects, and for getting them right in spite
of my garbling some of them in the original report.
I have updated the links for the next Mailman release.
___
Python tracker
<http://bugs.python.
Changes by Mark Sapiro :
--
nosy: +msapiro
___
Python tracker
<http://bugs.python.org/issue4288>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Sapiro added the comment:
This problem also occurs when building the 2.6.1 parser module on Cygwin
1.5.25. It did not occur with Python 2.6 or 2.5.x.
The error from 'make' is
building 'parser' extension
gcc -shared -Wl,--enable-auto-image-base
build/temp.cygwin-1.5.25
New submission from Mark Sapiro :
The Mailman GUI contains a few links to the python.org documentation
which are now broken. These links and the current equivalents are:
http://www.python.org/doc/
works, but could map to http://docs.python.org/
http://www.python.org/doc/current/
works
42 matches
Mail list logo
