hi there, folks:
I'd really like to release 0.7.0 but I would like it to be at least a
little bit tested before I do so. Could those of you with CVS trees check
everything out and see if it performs as advertised? Deeper bugs than
that will have to wait for the next release, but I'd at least like to know
if it works for someone other than me.
______ __ __ _____ _ _
| ____ | \_/ |_____] |_____|
|_____| |_____ | | | |
@ t w i s t e d m a t r i x . c o m
I filed https://twistedmatrix.com/trac/ticket/7970 last summer while
focused on a particular project that was hit by it. Since then I had to
attend to other things and I'm now back to refocusing on that project.
The subject says most of it, but the ticket has more information, including
why this isn't an issue on Python >= 3.4 ( my project is on 2.7...) :/
Before submitting a patch for review, I'm looking for preliminary feedback,
assuming you agree that the Windows vs POSIX semantics should be the same
(if not, why?).
My patch calls a few Windows APIs via ctypes, however, as far as I can
tell, Twisted on Windows requires pywin32 and, recently, there has been
some discussion around dropping that dependency and moving towards
something based on cffi.
What would you say the way forward is? Should I submit the patch for review
anyway? Is there any other work that needs to be done first that I may
Thanks in advance for Twisted and for your feedback,
Over the last few months, twistedmatrix.com's mailman installation has been used increasingly frequently to execute denial-of-service attacks against people's mailboxes. This is accomplished by sending huge numbers of subscription requests to our website, which in turn sends huge numbers of confirmation emails to their inbox. Based on some information that some targeted users have sent me, I now believe that this is to cause those users' mail quotas to be exceeded so that password reset or login notification emails won't reach them.
This has been going on for some time, but the frequency and severity of the attacks seem to be increasing; I only recently realized that this was considerably worse than an annoyance for those affected. I now have at least 1 confirmed report of this attack being a part of a (partially successful) identity theft.
This isn't the only problem we have with email:
We're running our own infrastructure which puts load on our already beyond-overloaded volunteer system administration team.
Despite running our own infrastructure, we are not dogfooding Twisted at all in the process, so we're not even learning anything useful from the pain; "exim is bad" is a lesson we've already learned many times, we do not need to keep learning it.
Given how hard it is for us to upgrade Mailman in our current system, we aren't even dogfooding our fellow community project terribly well.
Our infrastructure runs on the same host as the website and the buildmaster, overloading a very creaky system.
In addition to mailing lists, we run a mail forwarder. Our server's sender reputation is ... not great. We don't have SPF records, we don't do DKIM, and we don't provide authenticated SMTP for users, so emails just come from "wherever" when they are sent from, e.g. 'glyph(a)twistedmatrix.com' :-).
In order to address this, as soon as I can reasonably manage to do so, I will be moving Twisted's email infrastructure to mailgun.com <http://mailgun.com/>, a product that I've been successfully using for a range of personal domains (in particular, the divmod.com <http://divmod.com/> email forwarder - yes, I still operate that, when the Twisted community promises you an email address for life you get it ;-)). Additionally, Mailgun uses a bunch of Twisted within their infrastructure, so (although we won't be operating it) we will actually be dogfooding considerably more.
(Mailgun is a product of my employer, Rackspace, but they've given us a generous open source discount so there's no conflict of interest; the Twisted project won't be spending money on this.)
There will be a couple of inconveniences immediately after the transition:
At first, there will be no self-service subscription to mailing lists any more. If you want to subscribe, you'll have to send a message to twisted-python-owner(a)twistedmatrix.com <mailto:firstname.lastname@example.org> and the list administrator (right now, probably just me) will manually add your address. (Self-service unsubscription will still be possible.)
I'm not sure if I'll be able to keep the list archives at https://twistedmatrix.com/pipermail/ <https://twistedmatrix.com/pipermail/> updated, at least at first. I would encourage everyone to use http://news.gmane.org/gmane.comp.python.twisted <http://news.gmane.org/gmane.comp.python.twisted> and http://news.gmane.org/gmane.comp.python.twisted.web <http://news.gmane.org/gmane.comp.python.twisted.web> in the meanwhile.
Speaking of the contents of that sad URL, many disused mailing lists will be deleted. I doubt anyone will notice since there haven't been any posts to most of them in many years.
If you presently send email from a twistedmatrix.com <http://twistedmatrix.com/> address, you will probably want to start using the mailgun forwarder so that your messages will have nice shiny DKIM/SPF headers; I suspect you may start having more deliverability problems than you already do once other mail servers notice that we have said records if you're not using them. I'll distribute SMTP credentials via GPG-encrypted email to everyone I'm aware of who uses such an address.
There will be considerable benefits though:
For those of you with @twistedmatrix.com <http://twistedmatrix.com/> addresses, Mailgun operates a pretty conservative low-pass spam filter, but in looking at the analytics from my own personal domains, it really helps a lot and it is definitely more effective than the setup we've got right now.
Deliverability and mail-sending performance should be much improved; messages should arrive faster because they will be quarantined or deferred-bounced by major senders like GMail et. al. far less often, because we'll be forwarding less spam and legitimate messages will have appropriate anti-spam headers.
Trac will get faster at certain times because email DoSes should stop hitting the server.
Administrative overhead will decrease; we can just stop maintaining email ourselves.
Last but certainly not least, we'll stop being a collective unwilling accessory to cybercrime.
Probably these changes will all be pretty subtle, and most folks won't notice, but I wanted it to be clear in advance that they were intentional, in case there is some disruption associated with them :-). If anyone wants to give me a hand with parts of this (for example, setting up a smarthost configuration so that trac can still send email) please let me know.
I'm happy to announce that txJSON-RPC 0.5 is now available.
txJSON-RPC is a library for creating asynchronous json-rpc clients and
servers. It includes netstring and http support.
Please see the PyPI page for more information and downloads.
The high points in txJSON-RPC 0.5 are:
- First class support for Python 3 and PyPy
I am personally using this release of txJSON-RPC in production on
python3. However, as it is the first release with python 3 support,
please report any bugs. <https://github.com/rockstar/txjsonrpc/issues>
I have assumed maintainership of txJSON-RPC for Duncan MacGreggor,
original author of txJSON-RPC. I'd like to thank Duncan for his previous
work and for entrusting me with maintainership of txJSON-RPC going
One of the earliest protocols implemented in Twisted was AOL's instant messenger protocol. However, as explained on <https://twistedmatrix.com/trac/ticket/8260>, it doesn't really make sense for us to continue maintaining that code unless we can find someone actively interested in keeping it working against the production AIM service.
If you are interested in keeping this code alive, act quickly, before the deprecation makes it into a release and clears the way for a subsequent removal :-).
Currently, as far as I can tell, all implementations of
`IReactorTime.seconds()` (excluding twisted.internet.task.Clock, obviously)
are just `time.time()`; IOW, the return value is the number of seconds
since the beginning of the UNIX epoch in UTC. Are these the intended
semantics? The interface docstring doesn't really make this clear at all.
There's some commented out code which suggests the implementation used to
be `time.clock()` on win32, which would not satisfy these semantics.
(The background for this question is that I'm writing some code which takes
an IReactorTime provider for testing purposes, and I'm wondering if I need
a separate provider of `datetime.now()` functionality or not)