>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: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't
> change)
>
> He
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
> Otherwise it is easy to send an email with a domain that contains an
> extra letter and bypass DMARC.
It is ALWAYS easy to send an email with a domain that contains an
extra letter and bypass DMARC. Lookalike or "cousin" domains are
specifically not something it addresses.
Keep in mind that is
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
22 matches
Mail list logo
