Dear J. Gomez,
Oops. Multi-tasking too much between conversations it seems.
This is what was intended in the last paragraph.
The basic goal is to devise a means to establish informal federations of
domains with a goal of not altering messages. With this goal, it can therefore
be assumed to pr
On Jun 4, 2014, at 3:07 PM, J. Gomez wrote:
> On Wednesday, June 04, 2014 10:56 PM [GMT+1=CET], Douglas Otis wrote:
>
>> On Jun 4, 2014, at 12:16 PM, J. Gomez wrote:
>>
>>> On Wednesday, June 04, 2014 12:14 AM [GMT+1=CET], Hector Santos
>>> wrote:
>>>
I prefer to update my software wit
On Wed, Jun 4, 2014 at 10:43 AM, Stephen J. Turnbull
wrote:
> Nor does DMARC say it's nonconforming; in fact, it automatically
> passes identity alignment, because there's nobody who is allowed to
> create domains under .invalid, so there can be no _dmarc.x.y.invalid.
>
Actually, it does not and
John Levine writes:
> From what I can see on the mailman lists, looking for the internal
> DKIM signatures won't work too well, since mailman sometimes
> removes parts from multipart/alternative to fix to some formatting
> issue.
Mailman implements certain MIME structure manipulations as a pe
Franck Martin writes:
> Anyhow... my point is that moving an human decision to the machine
> is difficult, this is why we rely on protocols
Sure. That's why the U.S. military relies on landmines, too. "Smart
bombs" aren't perfect, obviously, but they're better than landmines!
DMARC "p=reject
J. Gomez writes:
> On Wednesday, June 04, 2014 9:34 PM [GMT+1=CET], John R Levine wrote:
> > > Obfuscating the domain is quite suspicious because then, what
> > > entity is taking responsibility for that email? What abuse
> > > help-desk can the potential receiver recourse to?
> >
> > The
>I'm beginning to lean towards liking the "embedded message" solution that
>mailman has, though. In my testing, it works mostly fine in Gmail, though
>it assumes (and prefixes with) "forwarded message". YMail's handling isn't
>that pretty, however, as it ignores the headers of the embedded messag
>I'm beginning to lean towards liking the "embedded message" solution that
>mailman has, though. In my testing, it works mostly fine in Gmail, though
>it assumes (and prefixes with) "forwarded message". YMail's handling isn't
>that pretty, however, as it ignores the headers of the embedded messag
On Wednesday, June 04, 2014 10:56 PM [GMT+1=CET], Douglas Otis wrote:
> On Jun 4, 2014, at 12:16 PM, J. Gomez wrote:
>
> > On Wednesday, June 04, 2014 12:14 AM [GMT+1=CET], Hector Santos
> > wrote:
> >
> > > I prefer to update my software with the above script for our MTA
> > > receiver rather
On Jun 4, 2014, at 12:16 PM, J. Gomez wrote:
> On Wednesday, June 04, 2014 12:14 AM [GMT+1=CET], Hector Santos wrote:
>
>> I prefer to update my software with the above script for our MTA
>> receiver rather to add logic to rewrite the 5322.From to bypass a
>> security protocol
>
> Rewriting th
On 6/4/2014 3:16 PM, J. Gomez wrote:
On Wednesday, June 04, 2014 12:14 AM [GMT+1=CET], Hector Santos wrote:
I prefer to update my software with the above script for our MTA
receiver rather to add logic to rewrite the 5322.From to bypass a
security protocol
Rewriting the Header-From field in m
Obfuscating the domain is quite suspicious because then, what entity is
taking responsibility for that email? What abuse help-desk can the
potential receiver recourse to?
The one whose DKIM signature is on the mail, of course. Sigh.
That would be the no-longer valid (assuming it ever was) and
On Wednesday, June 04, 2014 9:34 PM [GMT+1=CET], John R Levine wrote:
> > That is true, but it is not the same to obfuscate the local part in
> > the ReturnAddress/FromHeader, than to obfuscate the domain.
> >
> > Obfuscating the domain is quite suspicious because then, what
> > entity is taking
On Wed, Jun 4, 2014 at 12:34 PM, John R Levine wrote:
> That is true, but it is not the same to obfuscate the local part in the
>> ReturnAddress/FromHeader, than to obfuscate the domain.
>>
>> Obfuscating the domain is quite suspicious because then, what entity is
>> taking responsibility for tha
That is true, but it is not the same to obfuscate the local part in the
ReturnAddress/FromHeader, than to obfuscate the domain.
Obfuscating the domain is quite suspicious because then, what entity is taking
responsibility for that email? What abuse help-desk can the potential receiver
recourse
On Wednesday, June 04, 2014 5:44 AM [GMT+1=CET], John Levine wrote:
> > Yes the email is legitimate, but how does the MTA knows it?
> >
> > Well a bayesian filter has learned that this type of content is
> > legitimate, and then one day a spammer uses the same content, but
> > change one link...
On Wednesday, June 04, 2014 12:14 AM [GMT+1=CET], Hector Santos wrote:
> I prefer to update my software with the above script for our MTA
> receiver rather to add logic to rewrite the 5322.From to bypass a
> security protocol
Rewriting the Header-From field in mailing list traffic is not "bypassi
- Original Message -
> From: "Stephen J. Turnbull"
> To: "Hector Santos"
> Cc: "Tony Hansen" , dmarc@ietf.org, "Kurt Andersen"
> , "Franck Martin"
>
> Sent: Wednesday, June 4, 2014 10:43:16 AM
> Subject: Re:
Kurt Andersen writes:
> On Wed, Jun 4, 2014 at 10:43 AM, Stephen J. Turnbull
> wrote:
>
> > Nor does DMARC say it's nonconforming; in fact, it automatically
> >> passes identity alignment, because there's nobody who is allowed to
> >> create domains under .invalid, so there can be no _dmarc
On Wed, Jun 4, 2014 at 10:43 AM, Stephen J. Turnbull
wrote:
> Nor does DMARC say it's nonconforming; in fact, it automatically
>> passes identity alignment, because there's nobody who is allowed to
>> create domains under .invalid, so there can be no _dmarc.x.y.invalid.
>>
>
Actually, it does not
Hector Santos writes:
> [Mail From: a domain under .INVALID] is not legitimate mail per the
> proposed security protocol.
Sorry, in this subthread, "legitimate", as used by Franck and myself,
means "delivery desired by the addressee". If you want to insist on a
different definition, go ahead,
John, I doubt these aol and yahoo users give a hoot of what u snuck into your
small local site. The odds are high these kind of addresses were first used for
junk, aliases, "throw away" addresses like most people did with these public
email service bureaus. Sure, for many, these public addresses
But it does know. It is not legitimate mail per the proposed security protocol.
The problem and conversation should be focused on resolving the 9 years old
mail integration dilemma -- the dearth of resigners not wanting to check for
bad DKIM-secured transactions via a policy layer protocol. Kee
>But that is not equivalent to putting non-resolvable gibberish on the right
>side of the @ sign. That's
>a reliable way of assuring that such messages do not get queued on my server.
>As a matter of
>practicality, I highly doubt that I'm unique in requiring that the sender
>domain (envelope and
Franck Martin writes:
> Yes the email is legitimate, but how does the MTA knows it?
Aha! Precisely where this conversation should go.
The MTA *doesn't* know. A mailing list knows more, though. And an
MUA knows a lot more than that. Or they could.
For bandwidth reasons, it's important (espe
Brandon Long writes:
> You're being a bit free with the "we" there.
Sorry if you understood it that way. I'm here as a delegate of the
Mailman project, and in this case I believe my views are
representative of a working consensus of the core developers and some
influential users. So I wrote "w
Elizabeth Zwicky writes:
> But I do, in fact, have data, and that data tells me that the attackers
> forging our users based on stolen addressbooks have never stopped; we are
> still blocking them now.
Interesting. No perceptible change at all? I am going to have to dig
up that graph of the
- Original Message -
> From: "Matt Simerson"
> To: dmarc@ietf.org
> Sent: Tuesday, June 3, 2014 10:01:37 PM
> Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't
> change)
>
>
> On Jun 3, 2014, at 8:44 PM, John
On Jun 3, 2014, at 8:44 PM, John Levine wrote:
>> Yes the email is legitimate, but how does the MTA knows it?
>>
>> Well a bayesian filter has learned that this type of content is legitimate,
>> and then one day a spammer
>> uses the same content, but change one link...
>
> That could happen
>Yes the email is legitimate, but how does the MTA knows it?
>
>Well a bayesian filter has learned that this type of content is legitimate,
>and then one day a spammer
>uses the same content, but change one link...
That could happen to any mail feature you care to name.
Big companies send bucket
- Original Message -
> From: "Stephen J. Turnbull"
> To: "Franck Martin"
> Cc: "Tony Hansen" , dmarc@ietf.org, "Kurt Andersen"
>
> Sent: Tuesday, June 3, 2014 7:16:04 AM
> Subject: Re: [dmarc-ietf] DKIM through mailing lists
But why would you accept emails from invalid domains in the first
instance?
Because the email is legitimate, of course.
Until it isn't.
The purpose of the ".invalid" TLD was not for bypassing a proposed
security protocol. This is a malicious hack that will ultimately help
break down on
On Tue, Jun 3, 2014 at 12:43 PM, Brandon Long wrote:
>
> Remember, we think *all* of the mitigations should be discouraged in
>> favor of not permitting posts from "p=reject" domains. But we also
>> know that will be unacceptable to most of our list operators.
>
>
> You're being a bit free with
On 6/3/14, 4:26 AM, "Stephen J. Turnbull" wrote:
>Elizabeth Zwicky writes:
>
> > At this point, I do not see going to p=quarantine in the hope
> > that attackers won't exploit data they already have exactly the same
> > way
>
>Has Yahoo! has already tried 'p=quarantine', or is that merely your
Franck Martin writes:
> I'm not sure it is wise to encourage the use of "invalid" domains
> in any of the email headers.
Remember, we think *all* of the mitigations should be discouraged in
favor of not permitting posts from "p=reject" domains. But we also
know that will be unacceptable to mos
Franck Martin writes:
> But why would you accept emails from invalid domains in the first
> instance?
Because the email is legitimate, of course. I've seen people use
"example.com" in their addresses on list posts to ensure they won't
get personal replies. I've seen people use "nore...@person
Elizabeth Zwicky writes:
> At this point, I do not see going to p=quarantine in the hope
> that attackers won't exploit data they already have exactly the same
> way
Has Yahoo! has already tried 'p=quarantine', or is that merely your
expert opinion? (Nothing against expertise, but "experiment
- Original Message -
> From: "Kurt Andersen"
> To: "Stephen J. Turnbull" , "Tony Hansen"
>
> Cc: dmarc@ietf.org
> Sent: Monday, June 2, 2014 12:55:39 PM
> Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won
- Original Message -
> From: "Stephen J. Turnbull"
> To: "Tony Hansen"
> Cc: dmarc@ietf.org
> Sent: Monday, June 2, 2014 12:28:21 AM
> Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't
> change)
>
> Tony Hansen
I'm a list software product developer. I believe our list package was
among the
first to implement domains controls with restrictive domains. In our
case, we used the then IETF Proposed Standard ADSP. It followed the
guidelines written in the 2006 DSAP (DKIM Signature Authorization
Protocol) I
Tony Hansen writes:
> I would love to see that list of multiple mitigations shared with the
> broader community. That would be useful information for people in the
> IETF,
I've shared it here in various levels of detail more than once, and
sooner or later it will be in the Mailman FAQ as I'm
It is true that when attackers can't use our From: lines, they
try other things.
Empirically, it's also clear that the attackers do not like
From: "Victim Name"
as much as they like
From: "Victim Name"
based on lowered volume when the second form is unavailable. Given that,
I see no reason
>That's okay -- it was just a thought. However, note that not all MLMs
>are in as good a shape as GNU Mailman is, volunteer-wise. For *them*, it
>might be useful.
I wouldn't count on it. I did .invalid patches for majordomo2, which
is largely abandonware but still used a fair number of places.
Thanks for your comments Stephen.
On 5/31/14, 1:51 PM, Stephen J. Turnbull wrote:
Tony Hansen writes:
>> That doesn't help the DMARC situation now, but DMARC could be
>> given other options once that happens.
>
> I agree completely that a change to DMARC is needed in conjunction
> wit
Tony Hansen writes:
>> That doesn't help the DMARC situation now, but DMARC could be
>> given other options once that happens.
>
> I agree completely that a change to DMARC is needed in conjunction
> with having clear ML specs.
A change to the protocol? What? I don't see it. The protocol
Elizabeth Zwicky writes:
> So changes that maintain effective protection for users who are
> being targeted by attackers with addressbook information, with less
> disruption to email that people want, are of great interest to us.
How about trying "p=quarantine" with a real short TTL just in ca
On 05/30/2014 11:28 AM, Stephen J. Turnbull wrote:
> I am of the opinion that the technical DMARC protocols (including
> "p=reject") are fine. I have not heard of any complaint about use by
> banks (Bank of America joined the ranks of "p=reject" banks some time
> in the last 10 days AFAICT). Have
Murray S. Kucherawy writes:
> > DMARC change is even more off the table than MLM software change
> > (which does, as you suggest, evolve over time).
>
> Are there changes people want to make?
I am of the opinion that the technical DMARC protocols (including
"p=reject") are fine. I have not
On Friday, May 30, 2014 17:07:30 Elizabeth Zwicky wrote:
> On 5/29/14, 8:44 PM, "Scott Kitterman" wrote:
> >DMARC change is even more off the table than MLM software change (which
> >does,
> >as you suggest, evolve over time).
>
> DMARC changes are not off the table for Yahoo. Right now, the opti
On 5/29/14, 8:44 PM, "Scott Kitterman" wrote:
>DMARC change is even more off the table than MLM software change (which
>does,
>as you suggest, evolve over time).
DMARC changes are not off the table for Yahoo. Right now, the option that
best serves the majority of our customers is one that also
On May 30, 2014 3:37:28 AM EDT, "Murray S. Kucherawy"
wrote:
>On Thu, May 29, 2014 at 8:44 PM, Scott Kitterman
>wrote:
>
>> The reason there is no IETF working group is that the people behind
>DMARC
>> were
>> unwilling to entertain participation in a working group that had a
>charter
>> that al
On Thu, May 29, 2014 at 8:44 PM, Scott Kitterman
wrote:
> The reason there is no IETF working group is that the people behind DMARC
> were
> unwilling to entertain participation in a working group that had a charter
> that allowed for any chance of a change to the DMARC protocol.
>
I think that'
Dear Tony,
See comments inline:
On May 29, 2014, at 8:11 PM, Tony Hansen wrote:
> On 5/28/14, 6:46 PM, Barry Leiba wrote:
>> Anything that requires mailing list software to change won't work.
>
> I'm going to push back on this statement. I think we keep getting stuck on
> the mantra that "th
On Thursday, May 29, 2014 23:11:28 Tony Hansen wrote:
> On 5/28/14, 6:46 PM, Barry Leiba wrote:
> > Anything that requires mailing list software to change won't work.
>
> I'm going to push back on this statement. I think we keep getting stuck
> on the mantra that "the mailing list software won't c
On 5/28/14, 6:46 PM, Barry Leiba wrote:
Anything that requires mailing list software to change won't work.
I'm going to push back on this statement. I think we keep getting stuck
on the mantra that "the mailing list software won't change". However,
the majority of the mailing list software pa
55 matches
Mail list logo
