clone 752084 -1
reassign -1 bugs.debian.org
retitle -1 The Debian BTS needs a plan to deal with messages from DMARC
p=reject domains
thanks
Please see #752084 for the details.
The BTS too needs a solution to this, and it will be an harder problem
since it does not have the option of not
On Thursday, June 19, 2014 17:40:43 Alexander Wirt wrote:
On Thu, 19 Jun 2014, Marco d'Itri wrote:
On Jun 19, Marco d'Itri m...@linux.it wrote:
I propose that:
- we immediately start rejecting mails to our lists sent from domains
with a p=reject policy to prevent unsubscribing
On Sat, 21 Jun 2014, Scott Kitterman wrote:
On Thursday, June 19, 2014 17:40:43 Alexander Wirt wrote:
On Thu, 19 Jun 2014, Marco d'Itri wrote:
On Jun 19, Marco d'Itri m...@linux.it wrote:
I propose that:
- we immediately start rejecting mails to our lists sent from domains
Marco d'Itri, 2014-06-19 16:10+0200:
The possible solutions are:
a) keep rejecting mail from these domains
b) rewrite the From headers of messages from these domains
c) implement a permanent and elegant solution like
On Fri, 20 Jun 2014, Tanguy Ortolo wrote:
Marco d'Itri, 2014-06-19 16:10+0200:
The possible solutions are:
a) keep rejecting mail from these domains
b) rewrite the From headers of messages from these domains
c) implement a permanent and elegant solution like
On Jun 20, Alexander Wirt formo...@debian.org wrote:
If a user from a p=reject domain posts to our mailinglist, every subscriber
from a domain checking dmarc will get a bounce.
No, he is right: if the message is not modified then the DKIM signature
will be valid. This is one of the solutions
On Fri, 20 Jun 2014, Marco d'Itri wrote:
On Jun 20, Alexander Wirt formo...@debian.org wrote:
If a user from a p=reject domain posts to our mailinglist, every subscriber
from a domain checking dmarc will get a bounce.
No, he is right: if the message is not modified then the DKIM signature
On Jun 20, Alexander Wirt formo...@debian.org wrote:
No, he is right: if the message is not modified then the DKIM signature
will be valid. This is one of the solutions implemented by mailman.
what in detail means unmodified? body? headers?
The body and the DKIM-signed headers. E.g. gmail
On Fri, 20 Jun 2014, Marco d'Itri wrote:
On Jun 20, Alexander Wirt formo...@debian.org wrote:
No, he is right: if the message is not modified then the DKIM signature
will be valid. This is one of the solutions implemented by mailman.
what in detail means unmodified? body? headers?
On Jun 20, Alexander Wirt formo...@debian.org wrote:
h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type
Received? That probably means we cann add new received headers without
modifying the existing ones.
No, it means that you
On Fri, 20 Jun 2014, Marco d'Itri wrote:
On Jun 20, Alexander Wirt formo...@debian.org wrote:
h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type
Received? That probably means we cann add new received headers without
On Jun 20, Alexander Wirt formo...@debian.org wrote:
So, do you think too that we have a way to go here?
That means:
- don't add the footer for DKIM signed mails
- add DKIM on our own for outgoing mails to improve our own reputation
Yes (but these are unrelated goals).
But I think that it
On Fri, 20 Jun 2014, Marco d'Itri wrote:
On Jun 20, Alexander Wirt formo...@debian.org wrote:
So, do you think too that we have a way to go here?
That means:
- don't add the footer for DKIM signed mails
- add DKIM on our own for outgoing mails to improve our own reputation
Yes (but
On 20/06/14 10:44, Marco d'Itri wrote:
No, he is right: if the message is not modified then the DKIM signature
will be valid. This is one of the solutions implemented by mailman.
If it is viable and not too difficult to do this, then I'd ask the
listmasters to please consider it as a last
On Fri, 20 Jun 2014, Steven Chamberlain wrote:
On 20/06/14 10:44, Marco d'Itri wrote:
No, he is right: if the message is not modified then the DKIM signature
will be valid. This is one of the solutions implemented by mailman.
If it is viable and not too difficult to do this, then I'd ask
On Jun 20, Steven Chamberlain ste...@pyro.eu.org wrote:
Fortunately the main lists.d.o do not rewrite the subject, which would
have been the most inconvenient change to make. Still awkward for the
BTS and alioth lists.
Right, I forgot that this is relevant for the BTS as well since it
On 20/06/14 02:42, Don Armstrong wrote:
Would you mind pointing to the mails in the archives of the DMARC IETF
group where this was proposed? Want to try to address this if at all
possible, but don't want to re-hash things which have been addressed.
It wasn't a fun experience, it reminded me
On Fri, 20 Jun 2014, Tanguy Ortolo wrote:
Marco d'Itri, 2014-06-19 16:10+0200:
The possible solutions are:
a) keep rejecting mail from these domains
b) rewrite the From headers of messages from these domains
c) implement a permanent and elegant solution like
On Fri, 20 Jun 2014, Santiago Vila wrote:
On Fri, 20 Jun 2014, Tanguy Ortolo wrote:
Marco d'Itri, 2014-06-19 16:10+0200:
The possible solutions are:
a) keep rejecting mail from these domains
b) rewrite the From headers of messages from these domains
c) implement a
El 20/06/14 22:19, Alexander Wirt escribió:
read the bugreport again. at all.
Hmm. What makes you think I didn't?
Maybe you refer to the fact that your blog entry is dated from yesterday
and solutions for this problem which are acceptable for you have been
proposed in the bug report after
On Fri, 20 Jun 2014, Santiago Vila wrote:
El 20/06/14 22:19, Alexander Wirt escribió:
read the bugreport again. at all.
Hmm. What makes you think I didn't?
Maybe you refer to the fact that your blog entry is dated from yesterday and
solutions for this problem which are acceptable for you
El 20/06/14 22:37, Alexander Wirt escribió:
On Fri, 20 Jun 2014, Santiago Vila wrote:
El 20/06/14 22:19, Alexander Wirt escribió:
read the bugreport again. at all.
Hmm. What makes you think I didn't?
Maybe you refer to the fact that your blog entry is dated from yesterday and
solutions for
Package: lists.debian.org
Severity: important
Background on DMARC:
https://wordtothewise.com/2014/04/brief-dmarc-primer/
Official statements from Yahoo and AOL about their DMARC policy changes:
http://yahoo.tumblr.com/post/82426971544/an-update-on-our-dmarc-policy-to-protect-our-users
On Jun 19, Marco d'Itri m...@linux.it wrote:
I propose that:
- we immediately start rejecting mails to our lists sent from domains
with a p=reject policy to prevent unsubscribing innocent third parties
This requires installing opendmarc and its dependencies and verifying
the results in
On Thu, 19 Jun 2014, Marco d'Itri wrote:
On Jun 19, Marco d'Itri m...@linux.it wrote:
I propose that:
- we immediately start rejecting mails to our lists sent from domains
with a p=reject policy to prevent unsubscribing innocent third parties
This requires installing opendmarc and
Hi,
DMARC is so obviously broken in this regard. I tried but couldn't find
anyone with influence on the DMARC working group who cared about this
issue. It was 'outside of scope' or something.
I think Debian and other communities should really use their influence
here; simply go with option 1
On Fri, 20 Jun 2014, Steven Chamberlain wrote:
DMARC is so obviously broken in this regard. I tried but couldn't find
anyone with influence on the DMARC working group who cared about this
issue. It was 'outside of scope' or something.
Would you mind pointing to the mails in the archives of
27 matches
Mail list logo
