Re: [Mailman-Developers] Patch for HyperArch

[Mark Sapiro]

On 03/10/2016 10:10 AM, Mark Sapiro wrote:
> 
> For the actual "fix", my inclination is to modify the _set_date method
> in pipermail.py (this is called from Hyperarch.py as
> self.__super_set_date(message) just before it does self.fromdate =
> time.ctime(int(self.date)).
> 
> I would have this check the date and if it's not within say 50 years of
> now, replace the date with something reasonable. My question at this
> point is what's that something reasonable. I think it comes down to a
> choice between the From_ date if that's reasonable or the current date,
> but I don't know which is better.


I have reported this bug and fixed it. The bug is
 and the fix is


The fix looks at message timestamps in the following order:

The Date: header if any
An X-List-Received-Date header if any
The last Received: header if any
The Unix From_ line

The first parseable date which is in the current epoch (>= 1970) and not
more than mm_cfg.ARCHIVER_ALLOWABLE_SANE_DATE_SKEW (default 15 days) in
the future is accepted. If none of those produce an acceptable date, the
current time is used.

This differs from past behavior by the addition of range checks on the
date and the addition of Received: and Unix From_ date checks.

The Received: header check is important. For an "imported" mbox, the
From_ separators may reflect when the mbox was exported from it's source
rather than the message date. If the messages have Received: headers,
the later ones at least tend to have good dates.

-- 
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
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

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

Re: [Mailman-Developers] List Passwords via Mailman REST api

[Barry Warsaw]

On Mar 10, 2016, at 12:54 PM, Dominic Dambrogia wrote:

>If you can point me towards how to set passwords via the REST api or a hint
>of why I'm failing to moderate emails I would truthfully appreciate it.

Hi Dominic,

Currently the moderator_password can't be set via REST.  You would have to do
it from the mailman shell.

It's probably an easy addition, and I wouldn't be opposed, but there's the
open question as to whether the moderator password is a good idea in the long
term.  But, since that's the way it currently works, it probably makes sense
to allow setting it via REST.

Cheers,
-Barry
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

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

[Mailman-Developers] List Passwords via Mailman REST api

[Dominic Dambrogia]

Hi, my name is Dominic. I'm on the final steps of finishing my Mailman
mailing list server. The last problem I'm having is moderating emails.
Everything for mailman on my application is written in a PHP wrapper class
built around your REST api. Currently, we have no passwords set for lists,
so when we reply to our moderation requests for nonmembers posting to
mailing lists with "Approved: " or "Approved:", our moderation actions are
failing. I've been living in your pythonhosted documentation as of recently
and have yet to find anything about setting passwords for lists via the
REST api. If you can point me towards how to set passwords via the REST api
or a hint of why I'm failing to moderate emails I would truthfully
appreciate it.
Thank you,
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

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

Re: [Mailman-Developers] Help regarding an error during installation

[Abhilash Raj]

Hi Daman,

On 03/10/2016 07:18 AM, Daman Singh wrote:
> Hello everyone!
> 
> I am trying to install mailman for development using mailman-bundler. I
> followed  the instructions given here
> http://mailman-bundler.readthedocs.org/en/latest/ , but i am facing a
> problem.
> When i run buildout command i get an error saying,"no module named 'zlib'"
> but on running ipython, when i import zlib it works all right.

When running buildout in mailman-bundler, it generally creates a
virtualenv of its own, which might not have 'zlib not installed in it.
Just look for the virtualenv that gives this error(it could be venv-3.4,
that bundler makes for running mailman in), activate that, and install
'zlib in there.

I am not sure where is this error coming from, but for general python
projects, this is a general solution.


-- 
thanks,
Abhilash Raj
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

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

[Mailman-Developers] Interested in the GSoC idea 'GitLab/development tools integration'

[Wasim Thabraze]

Hello everyone,

I am Wasim Thabraze, a Computer Science Undergraduate. I have thoroughly
gone through the GSoC ideas page and have narrowed down my choices to the
project 'GitLab/development tools integration'.

I have experience with GitLab, GitHub and also used their API's to build
stuff.

I have gone through the idea and got a rough idea about how the final
outcome of the tool should be.

I feel glad if someone can help me in getting started with this project.



I hope I can code with Mailman this summer, and I really appreciate your
comments.


Regards,
Wasim

https://github.com/waseem18

http://www.thabraze.me
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

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

Re: [Mailman-Developers] Patch for HyperArch

[Mark Sapiro]

On 03/10/2016 03:19 AM, Sebastian Hagedorn wrote:
> 
> Unless you're really interested in the other differences you referred to
> in your other message, I won't bother to analyze them further. It seems
> clear to me that you have identified the main issue.


I understand the issue, and I know how to "fix" it.

I'm a bit uncertain about what to change a bad date to. Normally,
messages in the cumulative .mbox have at least three sources of date.
There is a Date: header, The mbox From_ separator line, and at least if
the message originally came via Mailman, an X-List-Received-Date: header
that was added by Mailman's ArchRunner when the message was archived.

Also, depending to an extent on site configuration, if the message was
originally archived by Mailman, it's archived Date: header will normally
be "close" to the time it was received by Mailman. See the code in the
_dispose() method in Mailman/Queue/ArchRunner.py.

So what this says is if a message in the mbox has a bad Date:, it is
probably from an imported mbox, and it's not clear that the From_ date
will be any better.

In the messages and excerpts you posted earlier, the From_ dates were
all within a few minutes of "Mon Nov  7 14:08:46 2005" which is probably
the time that portion of the mbox was built from a majordomo archive.

I have made a script at 
(mirrored at ) which
augments the standard bin/cleanarch script to also replace Date: headers
with the date from From_ if they differ by more than
mm_cfg.ARCHIVER_ALLOWABLE_SANE_DATE_SKEW (default = 15 days).

This may be sufficient. If you run it with the -n option against your
mbox, it will report the line #s of the bad dates, what they are and
what they would be changed to.

For the actual "fix", my inclination is to modify the _set_date method
in pipermail.py (this is called from Hyperarch.py as
self.__super_set_date(message) just before it does self.fromdate =
time.ctime(int(self.date)).

I would have this check the date and if it's not within say 50 years of
now, replace the date with something reasonable. My question at this
point is what's that something reasonable. I think it comes down to a
choice between the From_ date if that's reasonable or the current date,
but I don't know which is better.

Does anyone have an idea?

-- 
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
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

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

Re: [Mailman-Developers] Basic workflow of the ARC implementation

[Aditya Divekar]

Hi Steve!


> This should be trivial to do with the Python email package, too.  I
> don't really see that a separate module would be useful, since we'll
> want to extract a fixed set of headers (ARC- and DKIM-specified).  Of
> course it should be factored into a separate function (or perhaps a
> generic "extract_fields" function and a couple of derivatives with the
> DKIM list (just DKIM-Signature?) and the ARC list (ARC-Seal,
> ARC-Authentication-Results, and ARC-Message-Signature).
>
>
Depending on the message, if it has previous Authentication Results added
as a header, that can be extracted too.  The entire message can be parsed,
and then all the possible headers involved in the authentication process,
ie. DKIM signature, Authentication results, ARC headers,  can be
 extracted. If not found, a suitable flag can be set for them. ie. example
- if no previous arc headers were found, a flag can be set. This can later
be used in deciding the flow of the mail such as the "i" tag value, whether
we need to perform ARC authentication for the previous ARC headers, and
other fields that depend on the occurrences of any previous ARC set.

Another factoring issue: should you "import dkimpy" and call

> dkimpy.foo, or should you "from dkimpy import foo, bar, baz"?
> (Doesn't need to be settled for a while, and you can even try both at
> a small cost in time and effort.)
>
> From what I've read, I should use the `from ... import ...` when the no of
methods required from the package is less, around 3-4, the entire package
is not required and when naming conflicts are to be minded.
But yes, I can settle it later during the coding part :)

 >Isn't this inaccurate?  This "i" must *match* the Seal "i", no?

Yes, I meant the same thing. The "i" tag for all the three AAR, AMS and the
AS will be the same , and will be one higher than the previous instance of
the "i" tag. If no previous instance is there, it will be 1.

 > a,t,s,d: These can again be obtained from the dkimpy package.
>  >
>  > bh: The body hash. This can be obtained from the package. Here, we set
> the
>  > canonicalization to 'relaxed' and get the body hash.
>
> "The package" == dkimpy, right?
>
> Yes.


>  > 3. ARC Authentication Results.
>  > The "i" tag simply takes on the value same as the above "i" tags.
>  > Now from our previous conversation, as you suggested, the
>  > authenticity of the previous MTA who sent us the mail is not sure
>  > to be trusted. So in the case where we don't trust the previous
>  > MTA, we will have to perform our own DMARC, SPF, DKIM testing of
>  > the recieved mail. If previous ARC chain exists i.e. cv=V, then we
>  > perform the ARC test too.
>
> I'm not sure you understood me.  We *always* verify the preceding
> MTA's claims, even if we trust them, because of spoofing and
> man-in-the-middle attacks on the Internet itself.  (More precisely,
> verification is required by the I-D, and the rationale is spoofing and
> MITM.)  The MTA we "may or may not trust" is our *own* MTA.
>
>
Yes. So for every mail we receive, we always perform the authentication
tests for spf,dkim, dmarc (and arc if present).


> No.  The mail cannot be proved authentic by ARC, but that may be due
> to changes to the message at intervening hops.  There may be more
> sophisticated tests (eg, a PGP signature on a MIME body) that can
> prove it authentic.
>
>
Okay.! So we need to only include the ARC Headers and forward the message
to the subscribers, and
leave it upto their MTAs to do the needful.

 > Now coming to the testing part. There can be a number of tests like
>  > verifying the generated ARC signature, changing the body of the
>  > message, failing when the implicitly signed AMS headers are changed
>  > and other such tests.
>
> This is a little vague, but testing is hard.  You'll learn it as you
> go along.
>

I will come up with at least a few concrete tests that need to be performed
for each of the modules given below (in the milestones), and run them by
you once before the proposal.

>
> I count about 9 well-defined tasks in your message that could be made
> into good milestones.  You should try to come up with your own list,
> but if you're really not happy with your list, send it to me and ask
> for help and I'll give you my ideas.
>
>
I have come up with the following probable milestones for the project. -
(The project has been divided into milestones on the basis of the separate
modules that will be created. Each module is a milestone).
1. ARC Authentication Result - spf verification code completed. tests
passed. merge request created.
2. ARC Authentication Result - dkim verification code completed. tests
passed. merge request created.
3. ARC Authentication Result - dmarc verification code completed. tests
passed. merge request created.
4. ARC Authentication Result - arc verification code completed. tests
passed. merge request created.
5. ARC Authentication Result - generate AAR from the previous milestones
code. tests passed. merge 

Re: [Mailman-Developers] Help regarding an error during installation

[Simon Hanna]

On 03/10/2016 04:18 PM, Daman Singh wrote:
> Hello everyone!
> 
> I am trying to install mailman for development using mailman-bundler. I
> followed  the instructions given here
> http://mailman-bundler.readthedocs.org/en/latest/ , but i am facing a
> problem.
> When i run buildout command i get an error saying,"no module named 'zlib'"
> but on running ipython, when i import zlib it works all right.
> I am using a virtualenvironment. Basically module named zlib is already
> installed but "buildout" command is still giving me error.
> Anyone having its fix kindly provide me its fix
I'm unaware of any dependency on zlib. If you want to install mailman for 
development please refer
to this wiki page

http://wiki.list.org/DEV/SetupDevEnvironment

___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

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

[Mailman-Developers] Help regarding an error during installation

[Daman Singh]

Hello everyone!

I am trying to install mailman for development using mailman-bundler. I
followed  the instructions given here
http://mailman-bundler.readthedocs.org/en/latest/ , but i am facing a
problem.
When i run buildout command i get an error saying,"no module named 'zlib'"
but on running ipython, when i import zlib it works all right.
I am using a virtualenvironment. Basically module named zlib is already
installed but "buildout" command is still giving me error.
Anyone having its fix kindly provide me its fix

Best
Daman
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

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

Re: [Mailman-Developers] Patch for HyperArch

[Sebastian Hagedorn]

--On 9. März 2016 um 15:15:20 -0800 Mark Sapiro  wrote:


We played around and found that the error is related to our version of
Python. Here's a minimal test script that shows the issue:

from email.Utils import parseaddr, parsedate_tz, mktime_tz, formatdate
print mktime_tz(parsedate_tz("Fri, 4 Feb 100 00:51:42 +0100 (MET)"));

That's the Date header from the single piece of legitimate mail. Python
2.4 throws the same exception you were seeing: "ValueError: year out of
range". However, our Python 2.7 (which we use for Mailman) does this:

-59008522098

When that value is then passed to time.ctime(), you get "ValueError:
timestamp out of range for platform time_t". We're on RHEL 5, and our
version of Python 2.7 is from the IUSCommunity repo:
python27-2.7.10-1.ius.el5. Which version of Python were you using?



Thinking about this a bit more, I think what you say is the crux of the
difference between yours and mine. In your Python,
time.ctime(-59008522098) throws the ValueError, and in mine it returns a
date string which may cause problems later on in the processing.

I think the difference is not with a Python version per se, but rather
with the underlying C environment and C library 'time' functions that
Python was compiled with.


That makes sense.


In any case, I think I now have enough understanding of the issue to
work up some kind of fix that will work in both your situation and mine.

Note that your original suggested patch won't solve the problem for me
because my time.ctime(-59008522098) does not throw a ValueError.


Right. Of course I didn't know that at the time :-)

Unless you're really interested in the other differences you referred to in 
your other message, I won't bother to analyze them further. It seems clear 
to me that you have identified the main issue.


Thanks for your help!
--
   .:.Sebastian Hagedorn - Weyertal 121 (Gebäude 133), Zimmer 2.02.:.
.:.Regionales Rechenzentrum (RRZK).:.
  .:.Universität zu Köln / Cologne University - ✆ +49-221-470-89578.:.
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

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