test

test

[cinap_lenrek]

--
test

Re: [9front] test

[Stanley Lieber]

[-- Attachment #1: Type: text/plain, Size: 17 bytes --]

     test 

     

[-- Attachment #2: Type: text/html, Size: 45 bytes --]

Re: [9front] test

[Calvin Morrison]

test

On Sat, 18 May 2019 at 10:29, Stanley Lieber <sl@stanleylieber.com> wrote:
>
> test
>

[9front] Test

[theinicke]

This is a test mail, whether mails from me are now received properly, please ignore.

Also thank you sl

--
Tobias Heinicke

[9front] test

[sl]

test

Re: [9front] test

[Stanley Lieber]

testicle is a go library that automatically posts regression test output on buzzfeed.

sl


> On Aug 25, 2021, at 10:50 AM, ori@eigenstate.org wrote:
> 
> Quoth kvik@a-b.xyz:
>> Testicle.
>> 
> 
> That's what you get when a test drips and then
> freezes, right?
> 
> 

Re: [9front] test

[ori]

Quoth kvik@a-b.xyz:
> Testicle.
> 

That's what you get when a test drips and then
freezes, right?

Re: [9front] test

[kvik]

Testicle.

Re: [9front] test

[Pavel Renev]

Also test.

[9front] test

[cinap_lenrek]

test

--
cinap

Re: [9front] test

[Stuart Morrow]

hi

[9front] test

[cinap_lenrek]

Re: [9front] test

[hiro]

thankfully we need not decide (yet) :)

Re: [9front] test

[Ethan Gardener]

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?).

Re: [9front] test

[hiro]

here's when it all started ;)
https://thehackernews.com/2014/04/yahoos-new-dmarc-policy-destroys-every.html

Re: [9front] test

[hiro]

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...

Re: [9front] test

[Stanley Lieber]

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

Re: [9front] test

[Kurt H Maier]

On Mon, Sep 21, 2020 at 10:51:46AM -0700, ori@eigenstate.org wrote:
> 
>  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.
> 

This is why on some lists (I think TUHS, maybe others) you get some
messages from the recipient (these are from non-DKIM senders) and some
messages from "Original Sender via TUHS" with a TUHS reply-to and TUHS
DKIM signature.

khm

Re: [9front] test

[ori]

> 
> OpenBSD mailing lists forward without munging.

On closer inspection, they also strip DKIM headers.

Re: [9front] test

[Lyndon Nerenberg]

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

Re: [9front] test

[hiro]

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
>

Re: [9front] test

[ori]

>>
>>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.

Re: [9front] test

[Stanley Lieber]

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

Re: [9front] test

[ori]

> 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.

Re: [9front] test

[hiro]

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 ;)

Re: [9front] test

[Stanley Lieber]

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

Re: [9front] test

[Stanley Lieber]

yeah

sl

Re: [9front] test

[sl]

worked.

sl

Re: [9front] TEST

[Stanley Lieber]

> On Jan 29, 2017, at 6:29 PM, cinap_lenrek@felloff.net wrote:
> 
> very good, can we go to warp?

Is that an order.

Sir.

sl

Re: [9front] TEST

[cinap_lenrek]

very good, can we go to warp?

--
cinap

Re: [9front] test

[cinap_lenrek]

works

--
cinap

Re: [9front] test

[mischief]

[-- Attachment #1: Type: text/plain, Size: 104 bytes --]

Test worked.

On January 9, 2016 11:09:50 PM PST, cinap_lenrek@felloff.net wrote:
>testing
>
>--
>cinap

[-- Attachment #2: Type: text/html, Size: 364 bytes --]

Re: [9front] test.

[Nick Owens]

test worked

On 01/04/2016 03:14 PM, cinap_lenrek@felloff.net wrote:
> test.
> 
> --
> cinap
> 

Re: [9front] test

[ian kremlin]

testo besto, here you go-go

On Tue, Nov 17, 2015 at 9:34 PM,  <sl@stanleylieber.com> wrote:
> This message is yet ANOTHER test.

Re: [9front] TEST

[hiro]

Then I trust you, too!

Re: [9front] TEST

[sl]

> 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

Re: [9front] TEST

[hiro]

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"

On 10/9/15, sl@stanleylieber.com <sl@stanleylieber.com> wrote:
> TEST
>

Re: [9front] TEST

[cinap_lenrek]

works.

Re: [9front] TEST

[Nick Owens]

IT WORKED

On Thu, Oct 8, 2015 at 7:42 PM,  <sl@stanleylieber.com> wrote:
> TEST

Re: [9front] test

[BurnZeZ]

> test

Test reply

Re: [9front] test

[cinap_lenrek]

works.

--
cinap

Re: [9front] test.

[Aram Hăvărneanu]

error: test failed, engaging automatic nuclear strike.

-- 
Aram Hăvărneanu

Re: [9front] test

[Kurt H Maier]

Quoting suharik <gleb.ax.sh@gmail.com>:

> No web archive yet?
>


It's available over 9p, I think.

khm

Re: [9front] test

[sl]

> No web archive yet?

No.

sl

Re: [9front] test

[suharik]

[-- Attachment #1: Type: text/plain, Size: 83 bytes --]

No web archive yet?



2013/11/11 BurnZeZ <brz-systemd-dev@intma.in>

> MORE TESTS

[-- Attachment #2: Type: text/html, Size: 389 bytes --]

Re: [9front] test

[BurnZeZ]

[-- Attachment #1: Type: text/plain, Size: 10 bytes --]

MORE TESTS

[-- Attachment #2: Type: image/jpeg, Size: 33140 bytes --]

Re: [9front] test

[sl]

> 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