* test
@ 2019-05-18 11:08 cinap_lenrek
2019-05-18 14:28 ` [9front] test Stanley Lieber
0 siblings, 1 reply; 47+ messages in thread
From: cinap_lenrek @ 2019-05-18 11:08 UTC (permalink / raw)
To: 9front
--
test
^ permalink raw reply [flat|nested] 47+ messages in thread
* [9front] Test
@ 2024-09-07 15:48 theinicke
0 siblings, 0 replies; 47+ messages in thread
From: theinicke @ 2024-09-07 15:48 UTC (permalink / raw)
To: 9front
This is a test mail, whether mails from me are now received properly, please ignore.
Also thank you sl
--
Tobias Heinicke
^ permalink raw reply [flat|nested] 47+ messages in thread
* [9front] test
@ 2021-09-06 1:02 sl
0 siblings, 0 replies; 47+ messages in thread
From: sl @ 2021-09-06 1:02 UTC (permalink / raw)
To: 9front
test
^ permalink raw reply [flat|nested] 47+ messages in thread
* [9front] test
@ 2021-08-25 8:41 cinap_lenrek
2021-08-25 9:11 ` Pavel Renev
0 siblings, 1 reply; 47+ messages in thread
From: cinap_lenrek @ 2021-08-25 8:41 UTC (permalink / raw)
To: 9front
test
--
cinap
^ permalink raw reply [flat|nested] 47+ messages in thread
* [9front] test
@ 2021-08-21 22:29 cinap_lenrek
2021-08-21 23:49 ` Stuart Morrow
0 siblings, 1 reply; 47+ messages in thread
From: cinap_lenrek @ 2021-08-21 22:29 UTC (permalink / raw)
To: 9front
^ permalink raw reply [flat|nested] 47+ messages in thread
* test
@ 2020-09-21 15:40 kvik
2020-09-21 17:12 ` [9front] test Stanley Lieber
0 siblings, 1 reply; 47+ messages in thread
From: kvik @ 2020-09-21 15:40 UTC (permalink / raw)
To: 9front
I've changed DMARC policy to 'none'.
Let's see if this mail still gets to spam.
P.S. Sorry for spamming the list.
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [9front] test
2020-09-21 15:40 test kvik
@ 2020-09-21 17:12 ` Stanley Lieber
2020-09-21 17:16 ` hiro
0 siblings, 1 reply; 47+ messages in thread
From: Stanley Lieber @ 2020-09-21 17:12 UTC (permalink / raw)
To: 9front
On September 21, 2020 11:40:20 AM EDT, kvik@a-b.xyz wrote:
>I've changed DMARC policy to 'none'.
>
>Let's see if this mail still gets to spam.
>
>P.S. Sorry for spamming the list.
message received.
sl
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [9front] test
2020-09-21 17:12 ` [9front] test Stanley Lieber
@ 2020-09-21 17:16 ` hiro
2020-09-21 17:36 ` ori
0 siblings, 1 reply; 47+ messages in thread
From: hiro @ 2020-09-21 17:16 UTC (permalink / raw)
To: 9front
this example has cleared up for me why gmail does such stupidity,
sadly they were misleading and claimed the spam classification was due
to "similar to other spam".
i can confirm that most of the incorrectly classified spam messages i
get in gmail seem to have dmarc not set to none.
i checked a few exemplary senders, one of which being a web forum with
quite a few messages every day.
gmail itself also has it's dmarc set to none.
so while gmail wants to force you to use dmarc (unverified, somebody
claimed that on irc once) they don't seem to think anybody should have
to act upon it in any way ;)
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [9front] test
2020-09-21 17:16 ` hiro
@ 2020-09-21 17:36 ` ori
2020-09-21 17:40 ` Stanley Lieber
0 siblings, 1 reply; 47+ messages in thread
From: ori @ 2020-09-21 17:36 UTC (permalink / raw)
To: 23hiro, 9front
> this example has cleared up for me why gmail does such stupidity,
> sadly they were misleading and claimed the spam classification was due
> to "similar to other spam".
>
> i can confirm that most of the incorrectly classified spam messages i
> get in gmail seem to have dmarc not set to none.
> i checked a few exemplary senders, one of which being a web forum with
> quite a few messages every day.
>
> gmail itself also has it's dmarc set to none.
>
> so while gmail wants to force you to use dmarc (unverified, somebody
> claimed that on irc once) they don't seem to think anybody should have
> to act upon it in any way ;)
I'll pile on and summarize the discussion from cat-v
earlier today:
Kvik's email was being shitcanned on gmail because
of his dkim conflicting with our munging. Dkim signs
headers that it expects anyone forwarding mail to
leave untouched. Kvik's list was excessive, but most
dkim configs will be unhappy with our rewrites, since
they want the subject left untouched.
That leaves us 3 options:
1. Strip out DKIM entirely from forwarded emails.
2. Don't mess with any headers we don't need to
3. Implement DKIM, munge to our heart's content,
and re-sign.
My vote is in favor of 2 right now, and maybe 3 if we
ever implement dkim in upas.
This seems like a good summary of the situation.
https://begriffs.com/posts/2018-09-18-dmarc-mailing-list.html
For reference, the headers gmail doesn't want us to touch are:
mime-version:in-reply-to:references:from:date:message-id:subject:to;
Not sure what the other big providers want.
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [9front] test
2020-09-21 17:36 ` ori
@ 2020-09-21 17:40 ` Stanley Lieber
2020-09-21 17:51 ` ori
` (2 more replies)
0 siblings, 3 replies; 47+ messages in thread
From: Stanley Lieber @ 2020-09-21 17:40 UTC (permalink / raw)
To: 9front
On September 21, 2020 1:36:11 PM EDT, ori@eigenstate.org wrote:
>> this example has cleared up for me why gmail does such stupidity,
>> sadly they were misleading and claimed the spam classification was
>due
>> to "similar to other spam".
>>
>> i can confirm that most of the incorrectly classified spam messages i
>> get in gmail seem to have dmarc not set to none.
>> i checked a few exemplary senders, one of which being a web forum
>with
>> quite a few messages every day.
>>
>> gmail itself also has it's dmarc set to none.
>>
>> so while gmail wants to force you to use dmarc (unverified, somebody
>> claimed that on irc once) they don't seem to think anybody should
>have
>> to act upon it in any way ;)
>
>I'll pile on and summarize the discussion from cat-v
>earlier today:
>
>Kvik's email was being shitcanned on gmail because
>of his dkim conflicting with our munging. Dkim signs
>headers that it expects anyone forwarding mail to
>leave untouched. Kvik's list was excessive, but most
>dkim configs will be unhappy with our rewrites, since
>they want the subject left untouched.
>
>That leaves us 3 options:
>
> 1. Strip out DKIM entirely from forwarded emails.
> 2. Don't mess with any headers we don't need to
> 3. Implement DKIM, munge to our heart's content,
> and re-sign.
>
>My vote is in favor of 2 right now, and maybe 3 if we
>ever implement dkim in upas.
>
>This seems like a good summary of the situation.
>
> https://begriffs.com/posts/2018-09-18-dmarc-mailing-list.html
>
>For reference, the headers gmail doesn't want us to touch are:
>
> mime-version:in-reply-to:references:from:date:message-id:subject:to;
>
>Not sure what the other big providers want.
how does every other mailing list in the world manage modifying the subject line?
sl
^ permalink raw reply [flat|nested] 47+ messages in thread* Re: [9front] test
2020-09-21 17:40 ` Stanley Lieber
@ 2020-09-21 17:51 ` ori
2020-09-21 17:59 ` ori
2020-09-21 18:27 ` Kurt H Maier
2020-09-21 17:58 ` hiro
2020-09-21 17:59 ` Lyndon Nerenberg
2 siblings, 2 replies; 47+ messages in thread
From: ori @ 2020-09-21 17:51 UTC (permalink / raw)
To: 9front
>>
>>That leaves us 3 options:
>>
>> 1. Strip out DKIM entirely from forwarded emails.
>> 2. Don't mess with any headers we don't need to
>> 3. Implement DKIM, munge to our heart's content,
>> and re-sign.
>>
>
> how does every other mailing list in the world manage modifying the subject line?
>
> sl
From a non-comprehensive survey (some google groups,
9fans): Option 3: they rewrite stuff and sign it again
with their own key.
OpenBSD mailing lists forward without munging.
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [9front] test
2020-09-21 17:40 ` Stanley Lieber
2020-09-21 17:51 ` ori
@ 2020-09-21 17:58 ` hiro
2020-09-21 18:42 ` Stanley Lieber
2020-09-21 17:59 ` Lyndon Nerenberg
2 siblings, 1 reply; 47+ messages in thread
From: hiro @ 2020-09-21 17:58 UTC (permalink / raw)
To: 9front
option 1 and 3 would cover that
On 9/21/20, Stanley Lieber <sl@stanleylieber.com> wrote:
> On September 21, 2020 1:36:11 PM EDT, ori@eigenstate.org wrote:
>>> this example has cleared up for me why gmail does such stupidity,
>>> sadly they were misleading and claimed the spam classification was
>>due
>>> to "similar to other spam".
>>>
>>> i can confirm that most of the incorrectly classified spam messages i
>>> get in gmail seem to have dmarc not set to none.
>>> i checked a few exemplary senders, one of which being a web forum
>>with
>>> quite a few messages every day.
>>>
>>> gmail itself also has it's dmarc set to none.
>>>
>>> so while gmail wants to force you to use dmarc (unverified, somebody
>>> claimed that on irc once) they don't seem to think anybody should
>>have
>>> to act upon it in any way ;)
>>
>>I'll pile on and summarize the discussion from cat-v
>>earlier today:
>>
>>Kvik's email was being shitcanned on gmail because
>>of his dkim conflicting with our munging. Dkim signs
>>headers that it expects anyone forwarding mail to
>>leave untouched. Kvik's list was excessive, but most
>>dkim configs will be unhappy with our rewrites, since
>>they want the subject left untouched.
>>
>>That leaves us 3 options:
>>
>> 1. Strip out DKIM entirely from forwarded emails.
>> 2. Don't mess with any headers we don't need to
>> 3. Implement DKIM, munge to our heart's content,
>> and re-sign.
>>
>>My vote is in favor of 2 right now, and maybe 3 if we
>>ever implement dkim in upas.
>>
>>This seems like a good summary of the situation.
>>
>> https://begriffs.com/posts/2018-09-18-dmarc-mailing-list.html
>>
>>For reference, the headers gmail doesn't want us to touch are:
>>
>> mime-version:in-reply-to:references:from:date:message-id:subject:to;
>>
>>Not sure what the other big providers want.
>
> how does every other mailing list in the world manage modifying the subject
> line?
>
> sl
>
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [9front] test
2020-09-21 17:58 ` hiro
@ 2020-09-21 18:42 ` Stanley Lieber
2020-09-21 21:40 ` hiro
2020-09-22 12:57 ` Ethan Gardener
0 siblings, 2 replies; 47+ messages in thread
From: Stanley Lieber @ 2020-09-21 18:42 UTC (permalink / raw)
To: 9front
On September 21, 2020 1:58:17 PM EDT, hiro <23hiro@gmail.com> wrote:
>option 1 and 3 would cover that
>
>On 9/21/20, Stanley Lieber <sl@stanleylieber.com> wrote:
>> On September 21, 2020 1:36:11 PM EDT, ori@eigenstate.org wrote:
>>>> this example has cleared up for me why gmail does such stupidity,
>>>> sadly they were misleading and claimed the spam classification was
>>>due
>>>> to "similar to other spam".
>>>>
>>>> i can confirm that most of the incorrectly classified spam messages
>i
>>>> get in gmail seem to have dmarc not set to none.
>>>> i checked a few exemplary senders, one of which being a web forum
>>>with
>>>> quite a few messages every day.
>>>>
>>>> gmail itself also has it's dmarc set to none.
>>>>
>>>> so while gmail wants to force you to use dmarc (unverified,
>somebody
>>>> claimed that on irc once) they don't seem to think anybody should
>>>have
>>>> to act upon it in any way ;)
>>>
>>>I'll pile on and summarize the discussion from cat-v
>>>earlier today:
>>>
>>>Kvik's email was being shitcanned on gmail because
>>>of his dkim conflicting with our munging. Dkim signs
>>>headers that it expects anyone forwarding mail to
>>>leave untouched. Kvik's list was excessive, but most
>>>dkim configs will be unhappy with our rewrites, since
>>>they want the subject left untouched.
>>>
>>>That leaves us 3 options:
>>>
>>> 1. Strip out DKIM entirely from forwarded emails.
>>> 2. Don't mess with any headers we don't need to
>>> 3. Implement DKIM, munge to our heart's content,
>>> and re-sign.
>>>
>>>My vote is in favor of 2 right now, and maybe 3 if we
>>>ever implement dkim in upas.
>>>
>>>This seems like a good summary of the situation.
>>>
>>> https://begriffs.com/posts/2018-09-18-dmarc-mailing-list.html
>>>
>>>For reference, the headers gmail doesn't want us to touch are:
>>>
>>> mime-version:in-reply-to:references:from:date:message-id:subject:to;
>>>
>>>Not sure what the other big providers want.
>>
>> how does every other mailing list in the world manage modifying the
>subject
>> line?
>>
>> sl
>>
my point is, the implication is that dkim is both universally expected and desirable. is that really the case? it seems like just glossing over the question is silly. we need to make a decision (and modify it later, if necessary). if we need dkim, we should implement it. if not, not. right?
sl
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [9front] test
2020-09-21 18:42 ` Stanley Lieber
@ 2020-09-21 21:40 ` hiro
2020-09-21 22:20 ` hiro
2020-09-22 12:57 ` Ethan Gardener
1 sibling, 1 reply; 47+ messages in thread
From: hiro @ 2020-09-21 21:40 UTC (permalink / raw)
To: 9front
best to ask these people: https://www.mail-archive.com/mailop@mailop.org
imo if dkim+dmarc becomes popular enough I do expect that we (mailing
list operators) should change our convention and stop mangling headers
like the subject, from, or body of the mail.
but this is also only viable if people don't continue to use spf +
dmarc (!=none) without valid dkim, in the longer term. I'd say then
it's their own fault and there should be no way out provided by the
mailing list operator.
but i'd certainly wish that NONE of any above mentioned technologies
were used by anybody lest enforced. so definitely not desirable.
at this point i don't think there's a need for action. the early
adopters of strict dmarc setups deserve whatever punishment they are
experiencing for the upcoming while...
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [9front] test
2020-09-21 18:42 ` Stanley Lieber
2020-09-21 21:40 ` hiro
@ 2020-09-22 12:57 ` Ethan Gardener
2020-09-22 13:12 ` hiro
1 sibling, 1 reply; 47+ messages in thread
From: Ethan Gardener @ 2020-09-22 12:57 UTC (permalink / raw)
To: 9front
FYI, Gnu.org changed its mailing lists to not munge in October last year. (The explanation was approximately 10 times as long as this entire thread but not as clear, IMO. ;) The default for Mailman was also changed at that time.
I'm a little bit in favour of just not munging, but that's not a deeply considered opinion. I think it would only impact people who don't filter their mail (understandable?) and people who filter on subject (bad practice?).
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [9front] test
2020-09-21 17:40 ` Stanley Lieber
2020-09-21 17:51 ` ori
2020-09-21 17:58 ` hiro
@ 2020-09-21 17:59 ` Lyndon Nerenberg
2 siblings, 0 replies; 47+ messages in thread
From: Lyndon Nerenberg @ 2020-09-21 17:59 UTC (permalink / raw)
To: 9front
Stanley Lieber writes:
> how does every other mailing list in the world manage modifying the subjec=
> t line?
Poorly. They rewrite the From: and MAIL FROM addresses to match
the mailing list exploder address, thus completely destroying the
functionality of the From: header.
DMARC is a cluster fuck that must be made to die. Just don't do it.
--lyndon
^ permalink raw reply [flat|nested] 47+ messages in thread
* test
@ 2018-10-11 6:35 Ethan Gardener
2018-10-11 13:30 ` [9front] test Stanley Lieber
0 siblings, 1 reply; 47+ messages in thread
From: Ethan Gardener @ 2018-10-11 6:35 UTC (permalink / raw)
To: 9front
test
--
Progress might have been all right once, but it has gone on too long -- Ogden Nash
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [9front] test
@ 2017-03-18 21:04 sl
0 siblings, 0 replies; 47+ messages in thread
From: sl @ 2017-03-18 21:04 UTC (permalink / raw)
To: 9front
worked.
sl
^ permalink raw reply [flat|nested] 47+ messages in thread
* TEST
@ 2017-01-29 23:26 sl
2017-01-29 23:29 ` [9front] TEST cinap_lenrek
0 siblings, 1 reply; 47+ messages in thread
From: sl @ 2017-01-29 23:26 UTC (permalink / raw)
To: 9front
If you are reading this message, then mailing list service is resumed.
sl
^ permalink raw reply [flat|nested] 47+ messages in thread
* test
@ 2016-05-03 23:48 sl
2016-05-03 23:55 ` [9front] test cinap_lenrek
0 siblings, 1 reply; 47+ messages in thread
From: sl @ 2016-05-03 23:48 UTC (permalink / raw)
To: 9front
test
^ permalink raw reply [flat|nested] 47+ messages in thread
* test
@ 2016-01-10 7:09 cinap_lenrek
2016-01-10 7:42 ` [9front] test mischief
0 siblings, 1 reply; 47+ messages in thread
From: cinap_lenrek @ 2016-01-10 7:09 UTC (permalink / raw)
To: 9front
testing
--
cinap
^ permalink raw reply [flat|nested] 47+ messages in thread
* test.
@ 2016-01-04 23:14 cinap_lenrek
2016-01-04 23:18 ` [9front] test Nick Owens
0 siblings, 1 reply; 47+ messages in thread
From: cinap_lenrek @ 2016-01-04 23:14 UTC (permalink / raw)
To: 9front
test.
--
cinap
^ permalink raw reply [flat|nested] 47+ messages in thread
* test
@ 2015-11-18 2:34 sl
2015-11-18 5:01 ` [9front] test ian kremlin
0 siblings, 1 reply; 47+ messages in thread
From: sl @ 2015-11-18 2:34 UTC (permalink / raw)
To: 9front
This message is yet ANOTHER test.
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [9front] TEST
@ 2015-10-09 17:41 sl
2015-10-09 18:01 ` hiro
0 siblings, 1 reply; 47+ messages in thread
From: sl @ 2015-10-09 17:41 UTC (permalink / raw)
To: 9front
> google warns me that you would steal my identity
> "Be careful with this message. Similar messages were used to steal
> people's personal information. Unless you trust the sender, don't
> click links or reply with personal information. Learn More"
I trust Google.
sl
^ permalink raw reply [flat|nested] 47+ messages in thread
* TEST
@ 2015-10-09 2:42 sl
2015-10-09 2:44 ` [9front] TEST Nick Owens
` (2 more replies)
0 siblings, 3 replies; 47+ messages in thread
From: sl @ 2015-10-09 2:42 UTC (permalink / raw)
To: 9front
TEST
^ permalink raw reply [flat|nested] 47+ messages in thread* test
@ 2015-08-08 9:41 cinap_lenrek
2015-08-08 9:50 ` [9front] test BurnZeZ
0 siblings, 1 reply; 47+ messages in thread
From: cinap_lenrek @ 2015-08-08 9:41 UTC (permalink / raw)
To: 9front
test
--
cinap
^ permalink raw reply [flat|nested] 47+ messages in thread
* test
@ 2015-01-31 19:47 sl
2015-01-31 19:48 ` [9front] test cinap_lenrek
0 siblings, 1 reply; 47+ messages in thread
From: sl @ 2015-01-31 19:47 UTC (permalink / raw)
To: 9front
test
^ permalink raw reply [flat|nested] 47+ messages in thread
* test.
@ 2014-06-13 8:28 cinap_lenrek
2014-06-13 10:30 ` [9front] test Aram Hăvărneanu
0 siblings, 1 reply; 47+ messages in thread
From: cinap_lenrek @ 2014-06-13 8:28 UTC (permalink / raw)
To: 9front
test.
--
cinap
^ permalink raw reply [flat|nested] 47+ messages in thread
* test
@ 2013-11-11 1:35 cinap_lenrek
2013-11-11 1:40 ` [9front] test BurnZeZ
0 siblings, 1 reply; 47+ messages in thread
From: cinap_lenrek @ 2013-11-11 1:35 UTC (permalink / raw)
To: 9front
test test
--
cinap
^ permalink raw reply [flat|nested] 47+ messages in thread
* test
@ 2013-09-08 2:42 sl
2013-09-09 5:46 ` [9front] test sl
0 siblings, 1 reply; 47+ messages in thread
From: sl @ 2013-09-08 2:42 UTC (permalink / raw)
To: 9front
test.
sl
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [9front] test
2013-09-08 2:42 test sl
@ 2013-09-09 5:46 ` sl
0 siblings, 0 replies; 47+ messages in thread
From: sl @ 2013-09-09 5:46 UTC (permalink / raw)
To: 9front
> test.
Another copy got sent when I sent my previous reply.
I found some fun garbage in the mailing list queue. Two
addresses (one lavabit) failing every time the mailing
list attempted to send a message to them. We saw this
before, the last time duplicate messages were being
sent. Connection to the target server would fail for
whatever reason, then the mailing list would just
start over and attempt to send the message again,
to the entire list. Rinse and repeat, forever.
I've removed the offending addresses and cleaned
out the queue (again).
sl
^ permalink raw reply [flat|nested] 47+ messages in thread
end of thread, other threads:[~2024-09-07 15:51 UTC | newest]
Thread overview: 47+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-05-18 11:08 test cinap_lenrek
2019-05-18 14:28 ` [9front] test Stanley Lieber
2019-05-20 13:47 ` Calvin Morrison
-- strict thread matches above, loose matches on Subject: below --
2024-09-07 15:48 [9front] Test theinicke
2021-09-06 1:02 [9front] test sl
2021-08-25 8:41 cinap_lenrek
2021-08-25 9:11 ` Pavel Renev
2021-08-25 14:41 ` kvik
2021-08-25 14:46 ` ori
2021-08-25 14:56 ` Stanley Lieber
2021-08-21 22:29 cinap_lenrek
2021-08-21 23:49 ` Stuart Morrow
2020-09-21 15:40 test kvik
2020-09-21 17:12 ` [9front] test Stanley Lieber
2020-09-21 17:16 ` hiro
2020-09-21 17:36 ` ori
2020-09-21 17:40 ` Stanley Lieber
2020-09-21 17:51 ` ori
2020-09-21 17:59 ` ori
2020-09-21 18:27 ` Kurt H Maier
2020-09-21 17:58 ` hiro
2020-09-21 18:42 ` Stanley Lieber
2020-09-21 21:40 ` hiro
2020-09-21 22:20 ` hiro
2020-09-22 12:57 ` Ethan Gardener
2020-09-22 13:12 ` hiro
2020-09-21 17:59 ` Lyndon Nerenberg
2018-10-11 6:35 test Ethan Gardener
2018-10-11 13:30 ` [9front] test Stanley Lieber
2017-03-18 21:04 sl
2017-01-29 23:26 TEST sl
2017-01-29 23:29 ` [9front] TEST cinap_lenrek
2017-01-29 23:34 ` Stanley Lieber
2016-05-03 23:48 test sl
2016-05-03 23:55 ` [9front] test cinap_lenrek
2016-01-10 7:09 test cinap_lenrek
2016-01-10 7:42 ` [9front] test mischief
2016-01-04 23:14 test cinap_lenrek
2016-01-04 23:18 ` [9front] test Nick Owens
2015-11-18 2:34 test sl
2015-11-18 5:01 ` [9front] test ian kremlin
2015-10-09 17:41 [9front] TEST sl
2015-10-09 18:01 ` hiro
2015-10-09 2:42 TEST sl
2015-10-09 2:44 ` [9front] TEST Nick Owens
2015-10-09 3:12 ` cinap_lenrek
2015-10-09 9:04 ` hiro
2015-08-08 9:41 test cinap_lenrek
2015-08-08 9:50 ` [9front] test BurnZeZ
2015-01-31 19:47 test sl
2015-01-31 19:48 ` [9front] test cinap_lenrek
2014-06-13 8:28 test cinap_lenrek
2014-06-13 10:30 ` [9front] test Aram Hăvărneanu
2013-11-11 1:35 test cinap_lenrek
2013-11-11 1:40 ` [9front] test BurnZeZ
2013-12-05 13:16 ` suharik
2013-12-05 13:21 ` sl
2013-12-05 16:31 ` Kurt H Maier
2013-09-08 2:42 test sl
2013-09-09 5:46 ` [9front] test sl
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).