Milan Oberkirch added the comment:
This issue is a duplicate of issue 9112 which was resolved by commit 9375492b
--
nosy: +zvyn
___
Python tracker
<https://bugs.python.org/issue9
Milan Oberkirch added the comment:
The help states:
> usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
so I would argue that setup.py ignoring global_opts after cmd1 is not a bug.
But I do think that the fact that "python setup.py build --dry-run" does
Change by Milan Oberkirch :
--
keywords: +patch
pull_requests: +14524
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/14731
___
Python tracker
<https://bugs.python.org/issu
Milan Oberkirch added the comment:
Is there a reason for this still being open? /me trying to find issues to work
on using [random issue]
--
nosy: +zvyn
___
Python tracker
<https://bugs.python.org/issue21
Changes by Milan Oberkirch <milan...@oberkirch.org>:
--
nosy: -zvyn
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue12815>
___
_
Milan Oberkirch added the comment:
I tried to pin this leak down and got to the point where I suspect the compile
call:
def check_roundtrip(self, code1, filename="internal"):
ast1 = compile(code1, filename, "exec", ast.PyCF_ONLY_AST)
the leaks occur
Milan Oberkirch added the comment:
*Barry :P
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue21783>
___
___
Python-bugs-list
Milan Oberkirch added the comment:
Thanks for pointing me at this, Berry! I added a PR for aiosmtpd at
https://github.com/aio-libs/aiosmtpd/pull/106
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Milan Oberkirch added the comment:
I see your point, but I'm not fully convinced it relates to this PR directly:
the code here just uses the standard interface to use an 'idna' codec. If that
codec is buggy that is a different issue.
If it's so buggy that using it is absolutely pointless
Changes by Milan Oberkirch <milan...@oberkirch.org>:
--
pull_requests: +1979
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Milan Oberkirch added the comment:
I added a PR changing the exception raised as suggested, reviews welcome!
--
nosy: +zvyn
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Changes by Milan Oberkirch <milan...@oberkirch.org>:
--
pull_requests: +1977
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Milan Oberkirch added the comment:
Thanks for the feedback!
I changed the patch to use lstrip so that the FQDN "example.com." would match
the NOPROXY entry "example.com.". I don't think we get FQDNs, but that's just
my guess.
I think ideally "example.com"
Changes by Milan Oberkirch <milan...@oberkirch.org>:
--
type: behavior ->
versions: -Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file46168/ignore_dots-v2.patch
___
Python tracker <rep...@bugs.pytho
Milan Oberkirch added the comment:
Too bad, I was all exited when I saw that I can paste a PR link here :)
I downloaded the patch from the commit using github, I hope that works?
--
keywords: +patch
Added file: http://bugs.python.org/file46154/ignore_dots-v1.patch
Milan Oberkirch added the comment:
I added a line stripping dots from name, I think it makes sense to strip at the
end as well (`example.com` is the same domain as `example.com.`).
--
nosy: +zvyn
pull_requests: +8
___
Python tracker <
Milan Oberkirch added the comment:
pyshell.py is not part of CPython, this is the wrong place to report a bug like
this.
--
nosy: +zvyn
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Milan Oberkirch added the comment:
I shouldn't criticize my own patches if I want to have them committed:
Here comes the final and perfect patch for this issue ;)
(I only rephrased the comment for the test to make the intuition clear.)
--
Added file:
http://bugs.python.org/file40347
Milan Oberkirch added the comment:
*ping* This is still a reasonable patch. Would be great if you can apply it :)
--
nosy: +zvyn
versions: +Python 3.5, Python 3.6 -Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19663
Milan Oberkirch added the comment:
The other fixers you mentioned are deactivated independently of this patch if
an import from future_builtins exists. I gave it the same run_order as in the
fix for __future__ imports which prevents 2to3 from deleting the calls before
other fixers check
Milan Oberkirch added the comment:
Here is a simple patch that would solve this issue.
The new fixer 'future_builtins' removes `from future_builtins import foo`
statements if they aren't nested in other constructs (try-except, classes, ...)
and replaces them with `pass` otherwise
Milan Oberkirch added the comment:
Is this still relevant? I just made a patch based on the suggestions discussed
and it does not change the behavior of the original bug report (but fixed the
bug regarding '' mentioned by tony_nelson). Maybe I'm missing something?
--
keywords
Milan Oberkirch added the comment:
Here is the trivial patch for that :)
--
keywords: +patch
nosy: +zvyn
Added file: http://bugs.python.org/file39700/issue22872.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22872
Milan Oberkirch added the comment:
Here is the patch how it should look like at some point. Question being: How
should we handle backwards-compatibility?
--
keywords: +patch
Added file: http://bugs.python.org/file39699/issue21783.patch
___
Python
Milan Oberkirch added the comment:
After looking at this patch and how we implemented SMTPUTF8 in the parent class
again, I think we can come up with a more generic solution. Haven't it figured
out quite yet.
--
___
Python tracker rep
Milan Oberkirch added the comment:
I just wanted to note that this patch works with the current default repo as
expected. I will try to come up with some tests now (PureProxy is not tested at
all right now).
--
___
Python tracker rep
Milan Oberkirch added the comment:
Thanks a lot for reviewing my patch! I'm currently travalling so I'm totally
fine with you taking over this issue (would take me a few weeks till I can
work on it).
--
___
Python tracker rep...@bugs.python.org
New submission from Milan Oberkirch:
When using smtplib.SMTP to connect to a SMTP server the instance variables
esmtp_response survives a SMTP.quit() which results in the following error:
import smtplib
smtp = smtplib.SMTP('mail.oberkirch.org', 25)
smtp.starttls()
(220, b'2.0.0 Ready
Milan Oberkirch added the comment:
Thanks, for the review, here's comes an updated version.
--
Added file: http://bugs.python.org/file36370/issue21795v2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21795
Milan Oberkirch added the comment:
Thanks for your review comments, serhiy.storchaka!
I may be blind right now, but where did I add a positional parameter?
--
Added file: http://bugs.python.org/file36357/issue21725v5.4.patch
___
Python tracker rep
Milan Oberkirch added the comment:
Also the server should accept the SMTPUTF8 mail argument completely
independently of 8BITMIME if both are enabled.
--
title: smtpd.SMTPServer should announce 8BITMIME when supported -
smtpd.SMTPServer should announce 8BITMIME when supported
Milan Oberkirch added the comment:
Sorry, I was blind (switching between languages to much)! Anyway there should
be no existing code using decode_data as it was introduced in this development
circle.
--
___
Python tracker rep...@bugs.python.org
Milan Oberkirch added the comment:
The proposed patch extends process_message with an **kwargs catch-all which is
filled with 'mail_options' and 'rcpt_options' if decode_data is False. I also
removed process_smtputf8_message as one can detect the need for supporting
SMTPUTF8 from kwargs
Milan Oberkirch added the comment:
After blindly raising errors for 'SMTPUTF8' without 'BODY=.*' I found out that
'SMTPUTF8' alone is actually perfectly fine (for using international names in
addresses but sending ASCII data). Which means I did a mistake in the smtpd
patch :(
The attached 3rd
Milan Oberkirch added the comment:
I think that the peer arg is supposed to be set to the address of the peer
connecting to our server.
The value 'peer' comes from test/mock_socket.py:105 and is the best answer we
can get for mock_sock.getpeername() because there is no real client when
Changes by Milan Oberkirch milan...@oberkirch.org:
Added file: http://bugs.python.org/file36323/issue21725v5.2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21725
Changes by Milan Oberkirch milan...@oberkirch.org:
Added file:
http://bugs.python.org/file36324/smtplib_smtputf8_issue21725-dependentV2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22027
Changes by Milan Oberkirch milan...@oberkirch.org:
Added file: http://bugs.python.org/file36325/issue8503v2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8503
New submission from Milan Oberkirch:
This issue depends on issue 21725 for the communication with the client and
issue 22027 for communicating with the remote server.
I think I can come up with a patch for the default branch which is applicable
but will not run without the two other issues
New submission from Milan Oberkirch:
I fixed this for smtpd.DebuggingServer in the patch for issue 21725 but think
it is an independent issue which is resolvable with a small patch.
--
components: Library (Lib)
files: decode_data_proxy_debugging_server.patch
keywords: patch
messages
Changes by Milan Oberkirch milan...@oberkirch.org:
--
keywords: +patch
Added file: http://bugs.python.org/file36294/pp_smtputf8.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22158
Changes by Milan Oberkirch milan...@oberkirch.org:
Removed file:
http://bugs.python.org/file36159/smtpd_remove_deprecated_attrs_v2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22027
Milan Oberkirch added the comment:
Okay that was stupid from me (it was 5am when I submitted it), sorry.
--
Added file: http://bugs.python.org/file36271/imaplib_test_rfc3501v2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
New submission from Milan Oberkirch:
I finished writing tests for all methods which are specified in RFC 3501 but
left out extensions for now. The attached patch will trigger many resource
warnings. Do you have an idea why the sockets aren't closed?
--
files: imaplib_test_rfc3501
Milan Oberkirch added the comment:
AntoinePitrou: Thanks for the review!
I made the suggested changes and could not resist refactoring the hole thing
(since I plan to spend some time on that file I wanted it to be readable and
pep conform).
--
Added file: http://bugs.python.org
New submission from Milan Oberkirch:
The status quo of test_imaplib is a bit frustrating: 4 test functions out of 31
get executed by default while only few seem to need any resources.
I tried to solve this in the attached patch. Did I get something wrong or was
that checking for network
Changes by Milan Oberkirch milan...@oberkirch.org:
Removed file: http://bugs.python.org/file36170/imaplib_test.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22111
Changes by Milan Oberkirch milan...@oberkirch.org:
Added file: http://bugs.python.org/file36171/imaplib_test.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22111
Changes by Milan Oberkirch milan...@oberkirch.org:
Added file: http://bugs.python.org/file36157/issue21725v5.1.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21725
Changes by Milan Oberkirch milan...@oberkirch.org:
Added file:
http://bugs.python.org/file36158/smtpd_remove_deprecated_attrs_v2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22071
Changes by Milan Oberkirch milan...@oberkirch.org:
Added file:
http://bugs.python.org/file36159/smtpd_remove_deprecated_attrs_v2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22027
Milan Oberkirch added the comment:
Thanks for the review and improvements!
I fixed the warnings (didn't see them with running tests as described in the
dev guide; I may improve that later), updated the docs to RFC 5321 (issue 19679
is referring to RFC 3463 which is not required/updated
New submission from Milan Oberkirch:
I made a patch removing deprecated attributes from smtpd (as suggested by
r.david.murray).
--
components: Library (Lib)
files: smtpd_remove_deprecated_attrs.patch
keywords: patch
messages: 223969
nosy: jesstess, pitrou, r.david.murray, zvyn
priority
Milan Oberkirch added the comment:
This bug is fixed (at least in 3.5) so you might want to close it.
(See the _rset function in smtplib.py:482 and how its used in sendmail.)
--
nosy: +jesstess, zvyn
___
Python tracker rep...@bugs.python.org
http
Milan Oberkirch added the comment:
This bug was resolved for SMTPServerDisconnected exceptions but not for
SSLError. Is it still reproducible? If so, the attached patch should fix it for
3.x (couldn't test if it does because I don't know how to reproduce the error).
--
nosy: +jesstess
Milan Oberkirch added the comment:
I agree that there is not much we can do on the server side (see issue 19806)
and with the fix for issue 19662 the server won't recognize this error at all
(patiently waiting for b'\r\n\' which is unlikely to appear in the first
handshake-message from
New submission from Milan Oberkirch:
This patch is related to and depends on issue 21725. I put it here for review,
it can be applied (maybe with small changes) as soon as issue 21725 is fixed.
--
components: email
files: smtplib_smtputf8_issue21725-dependent.patch
keywords: patch
Milan Oberkirch added the comment:
After trying to implement SMTPS with asyncore and wrap_socket I agree with
David that it is at least hard: somehow the handshake fails
(ssl.SSLWantReadError) and I did not really figure out why. Looking at the
debugging output of openssl indicates
Changes by Milan Oberkirch milan...@oberkirch.org:
Added file: http://bugs.python.org/file35991/smtpd_AUTH_full2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21935
Milan Oberkirch added the comment:
My interpretation of this paragraph is the following (English is not my native
language so please correct me if I'm wrong):
The requirement is to provide a configuration where plain auth is disabled if
password snooping would be possible otherwise
Milan Oberkirch added the comment:
Done. I added the keyarg 'enable_AUTH' and two abstract methods to the server:
process_auth(user, password) for authentication and accept_recipient(user,
mailfrom, rcptto) for authorization.
--
Added file: http://bugs.python.org/file35974
Milan Oberkirch added the comment:
Note that in this (and my previous) patch the message is sent to the client
(the idea was not to raise an exception). Maybe it would be better to raise an
exception with the information you mentioned?
--
Added file:
http://bugs.python.org/file35975
Milan Oberkirch added the comment:
Agreed. It just feels a bit weird to send programming instructions for the
server to the client (but it's probably the best we can do here).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Milan Oberkirch added the comment:
We could solve issue 8503 at the same time by always calling
'accept_recipient(mailfrom, rcptto, user=None)' and providing a default
implementation for backwards compatibility.
--
___
Python tracker rep
Milan Oberkirch added the comment:
There is no real API in the current patch and authenticating has no effect
(other then preventing you from authenticating again and storing the username).
I am wondering how the user should turn AUTH on/off.
Solution 1:
add a keyword argument 'enable_AUTH
Changes by Milan Oberkirch milan...@oberkirch.org:
--
nosy: +jesstess
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19806
___
___
Python-bugs-list
Milan Oberkirch added the comment:
I do not think that the proposed patch solves the bug because it silently
changes binary input. With the patch for issue 19662 a proper solution to avoid
this bug has been applied. The only thing left is to prevent the server to
raise the exception when
Milan Oberkirch added the comment:
I patched it as you suggested (9 lines added/changed in total).
--
Added file:
http://bugs.python.org/file35903/imaplib_interpret_empty_string_as_None.patch
___
Python tracker rep...@bugs.python.org
http
Milan Oberkirch added the comment:
Ignore what I just did (the test is obviously dump; it fails if you run it on
an IMAP server). I'll make a new attempt after a coffee break ;)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Milan Oberkirch added the comment:
I'm still wondering if the test could be done better. At least it fixes the bug.
--
Added file:
http://bugs.python.org/file35904/imaplib_interpret_empty_string_as_NoneV2.patch
___
Python tracker rep
Changes by Milan Oberkirch milan...@oberkirch.org:
--
nosy: +zvyn
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12815
___
___
Python-bugs-list
New submission from Milan Oberkirch:
I implemented message processing for LOGIN and PLAIN authentication in smtpd. I
also patched test_smtplib to make use of this functionality.
The goal for the API is to provide decryption and message processing in the
smtpd library and call a externally
Milan Oberkirch added the comment:
I got the Exception policy of the POP3 class wrong (ignore my review comment on
that) and needed to add 'UTF8' to the list of optional commands.
--
Added file: http://bugs.python.org/file35823/poputf8-v2.patch
New submission from Milan Oberkirch:
I made a patch implementing the following changes to the IMAP4 class:
- add a method 'enable_UTF8_accept()' sending ENABLE UTF8=ACCEPT to the
server and setting internal encoding to UTF-8
- use the UTF8 extencion in the 'append()' method if the internal
New submission from Milan Oberkirch:
The poplib classes already use Unicode internally (for everything but
capability names). So to implement the UTF8 part of RFC 6856 we only need to
enable the user to switch to UTF-8 mode if supported by the server.
--
components: email
files
Changes by Milan Oberkirch milan...@oberkirch.org:
Removed file: http://bugs.python.org/file35686/poputf8.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21804
Changes by Milan Oberkirch milan...@oberkirch.org:
Added file: http://bugs.python.org/file35687/poputf8.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21804
New submission from Milan Oberkirch:
The smtpd.SMTPServer does support 8BITMIME if decode_date is False (#19662) and
could be announced under this condition. The patch for #21725 already
implements 8BITMIME so this can easily be done afterwards.
--
components: email
messages: 220868
Milan Oberkirch added the comment:
I replied to some review comments, and made a new patch implementing your
suggestions.
--
Added file: http://bugs.python.org/file35679/issue21725v3.patch
___
Python tracker rep...@bugs.python.org
http
Changes by Milan Oberkirch milan...@oberkirch.org:
--
components: email
nosy: barry, jesstess, pitrou, r.david.murray, zvyn
priority: normal
severity: normal
status: open
title: Implement RFC 6855 (IMAP Support for UTF-8) in imaplib.
versions: Python 3.5
New submission from Milan Oberkirch:
Sending HELO or EHLO more then once causes smtpd.SMTPChannel to respond with
b'503 Duplicate HELO/EHLO\r\n' (see Lib/test/test_smtpd.py:124 for an example).
My interpretation of RFC 821, section 4.1.1.5 is that multiple HELO commands
are fine outside
Milan Oberkirch added the comment:
The new patch implements what you suggested, with the following differences:
- I still use the default_dict and add the numbers up but maybe it's a bit more
readable now?
- Support for HELO/EHLO is a seperate issue #21783
--
Added file: http
Milan Oberkirch added the comment:
Thanks a lot for your feedback!
Your modifications to the handling of max_command_size are technically buggy
(and clearly there's no test for it): when we aren't in extended smtp mode,
the limit should be the hardcoded value, as in the original code. My
Changes by Milan Oberkirch milan...@oberkirch.org:
--
nosy: +jesstess, zvyn
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20083
___
___
Python
Milan Oberkirch added the comment:
Ping :)
--
nosy: +zvyn
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11783
___
___
Python-bugs-list mailing
Changes by Milan Oberkirch milan...@oberkirch.org:
--
nosy: +jesstess
Added file: http://bugs.python.org/file35565/issue11783.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11783
Milan Oberkirch added the comment:
Here comes an updated patch based on 'email_address_idna.patch' without
breaking smtplib (as the previous patches did).
--
Added file: http://bugs.python.org/file35566/issue11783-rdm-fixed.patch
___
Python tracker
Milan Oberkirch added the comment:
I merged it into https://bitbucket.org/zvyn/cpython and made a diff from that.
(I used bash for this so hopefully its compatible to the review system here.)
--
Added file: http://bugs.python.org/file35577/issue21725.patch
Changes by Milan Oberkirch milan...@oberkirch.org:
Added file: http://bugs.python.org/file35578/issue21725-fixed.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21725
Changes by Milan Oberkirch milan...@oberkirch.org:
Removed file: http://bugs.python.org/file35578/issue21725-fixed.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21725
Changes by Milan Oberkirch milan...@oberkirch.org:
Added file: http://bugs.python.org/file35579/issue21725-fixed.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21725
Changes by Milan Oberkirch milan...@oberkirch.org:
Added file: http://bugs.python.org/file35580/issue21725-fixed-hg.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21725
Milan Oberkirch added the comment:
Fixed it.
--
Added file: http://bugs.python.org/file35556/smtpd_061014.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14758
Changes by Milan Oberkirch milan...@oberkirch.org:
--
nosy: +jesstess, zvyn
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19662
___
___
Python
Milan Oberkirch added the comment:
I see no reason to restrict the filtering possibilities to the domain, so I
added a method validate_recipient_address wich gets an address of the form
local-part@domain and returns `True`.
SMTPChannel.smtp_RCPT checks any address with this method before
Milan Oberkirch added the comment:
I applied your suggestions.
--
Added file: http://bugs.python.org/file35542/smtpd_060914.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14758
Changes by Milan Oberkirch milan...@oberkirch.org:
--
nosy: +jesstess
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14758
___
___
Python-bugs-list
Milan Oberkirch added the comment:
Should this task get closed? (see comment above)
--
nosy: +jesstess
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20903
Milan Oberkirch added the comment:
Here comes the patch implementing your suggestions. Changing the API to make
adding new auth methods and still using login() would only require to make
preferred_auth accessable as you mentioned. Using custom authobjects is
possible with this patch
Milan Oberkirch added the comment:
Done.
--
Added file: http://bugs.python.org/file35392/smtplib_auth.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15014
1 - 100 of 122 matches
Mail list logo
