--On 23 October 2009 10:29:17 -0400 "John R. Levine" wrote:
>>> If, as I suspect, bad guys spoofing their way onto lists past admins
>>> unwilling to do inbound filtering is not an actual problem, perhaps we
>>> could agree not to waste time inventing mechanisms to solve it?
>>
>> I don't think
John Levine wrote:
>>> What is ironic about all this DKIM forwarding issue is the same issue
>>> that SPF forwarding had. This was one of the marketing advantages of
>>> DKIM - that it didn't have a forwarding problem.
>>>
>>> Well, it does. ...
>
>> It's also possible -- we'll have to see what
>> What is ironic about all this DKIM forwarding issue is the same issue
>> that SPF forwarding had. This was one of the marketing advantages of
>> DKIM - that it didn't have a forwarding problem.
>>
>> Well, it does. ...
>It's also possible -- we'll have to see what happens -- that mailing
>list
>> 1) Make DISCARD rejection a knob and see how it goes.
>> 2) For ALL or just plain old DKIM signatures, use that information
>> as an end receiver would to make a spam/ham decision, but
>> otherwise pass *everything* through to the final recipient even
>> if they're 100% sure they br
Barry Leiba wrote:
>> What is ironic about all this DKIM forwarding issue is the same issue
>> that SPF forwarding had. This was one of the marketing advantages of
>> DKIM - that it didn't have a forwarding problem.
>>
>> Well, it does.
>
> Indeed it does. But it doesn't have the forwarding pro
> What is ironic about all this DKIM forwarding issue is the same issue
> that SPF forwarding had. This was one of the marketing advantages of
> DKIM - that it didn't have a forwarding problem.
>
> Well, it does.
Indeed it does. But it doesn't have the forwarding problem for the
(large) class of
im] Issue: Deployment Guide Section 6.1/6.5
> (ADSP/Forwader) conflict
>
> My feeling is this:
>
> 1) Make DISCARD rejection a knob and see how it goes.
> 2) For ALL or just plain old DKIM signatures, use that information as
> an
> end receiver would to make a spam/h
I agree with most of this.
We need to trust software people and operators - in principle they are
not going to do something the specification does not say and is very
clear about it. We cane skeptical about it, but good engineering
faith is all we have. IMO, ADSP "discardable" is very clear.
I haven't seen the various lists proposals but two things:
1) what to do with ADSP discard is a legitimate discussion for list software
2) what to do with ALL is NOT. A list that discards or otherwise rejects a
submission *solely* on ALL is BROKEN. Doubly so if the ALL message had
a legiti
>>
> if you are rewriting the from and put the original sender in the sender:
> field, most MUA will display it like this:
>
> Sent by JD Falk
> on the behalf of DKIM-WG
Most? Only Outlook as far as I'm aware. Anyway, the use case here is an
announcement only mailing list, not a discussion list
--On 18 October 2009 20:55:38 -0400 Barry Leiba
wrote:
>>> That seems sensible to me. So lists should not forward email that
>>> they're about to render 'discardable' by breaking the signature.
>>> Instead, they should reject (5xx) or bounce (DSN) the message.
>>> Presumably, a bank wants to k
--On 19 October 2009 01:18:04 + John Levine wrote:
> I know what my lists do (just out of curiosity, how many other people
> in this argument host active lists?) and I know what works for me, but
> there are a lot of other opinions and we won't know what works until
> we have some actual ex
John R. Levine wrote:
>>> This is the mailing list advice that I strongly suggest we NOT attempt
>>> to provide at this point.
>
>> strongly disagree. Filtering early is more likely to pickup signature
>> breakage and protect the down stream recipient. Its more likely to
>> reject back to the s
On Monday 19 October 2009 12:18:04 John Levine wrote:
> >The point here, I suppose, is that forwarders that are meant to
> >forward ... while forwarders that are meant to fan out to multiple
> >recipients ... should get different advice.
>
> This is the mailing list advice that I strongly suggest
>> This is the mailing list advice that I strongly suggest we NOT attempt
>> to provide at this point.
> strongly disagree. Filtering early is more likely to pickup signature
> breakage and protect the down stream recipient. Its more likely to
> reject back to the sender if they configured stuff
> This is the mailing list advice that I strongly suggest we NOT attempt
> to provide at this point.
...
> there are a lot of other opinions and we won't know what works until
> we have some actual experience.
Geez, and here this is what I've been saying, and I got sucked into
the speculation anyw
Barry Leiba wrote:
> I suggest that ADSP-compliant mailing lists should be
> advised to reject "discardable" messages whether or not they will be
> breaking the signature.
Yes, this is a reasonable idea.
The question is whether it is the /right/ idea.
Another reasonable idea is that the m
>The point here, I suppose, is that forwarders that are meant to
>forward ... while forwarders that are meant to fan out to multiple
>recipients ... should get different advice.
This is the mailing list advice that I strongly suggest we NOT attempt
to provide at this point. All these arguments ab
>> That seems sensible to me. So lists should not forward email that they're
>> about to render 'discardable' by breaking the signature. Instead, they
>> should reject (5xx) or bounce (DSN) the message. Presumably, a bank wants
>> to know if it has a bad email address for a customer.
>
> Yep.
>
>>
- "J.D. Falk" wrote:
> Ian Eiloart wrote:
>
> > That seems sensible to me. So lists should not forward email that
> they're
> > about to render 'discardable' by breaking the signature. Instead,
> they
> > should reject (5xx) or bounce (DSN) the message. Presumably, a bank
> wants
> > to
Ian Eiloart wrote:
> That seems sensible to me. So lists should not forward email that they're
> about to render 'discardable' by breaking the signature. Instead, they
> should reject (5xx) or bounce (DSN) the message. Presumably, a bank wants
> to know if it has a bad email address for a custo
On Fri, 16 Oct 2009 00:27:57 +0100, hector
wrote:
> Charles Lindsey wrote:
>
>> There is no SHOULD|MUST about what recipients do
>
>
> I agree, but at some point implementators will need to transform the
> functional specification into a technical one. i.e. Software logic
> with options et
--On 14 October 2009 09:39:42 -0700 Steve Atkins
wrote:
>
> The whole point of "discardable" is that the final recipient should not
> see it in that case. It's for things like transactional mail, bank
> statements, that sort of thing - which should never go to mailing lists
anyway as
> the se
Charles Lindsey wrote:
> There is no SHOULD|MUST about what recipients do. At most, it is a matter
> of Best Common Practice, which this WG might well choose to incorporate in
> a BCP RFC. But what would such a BCP document say?
I agree, but at some point implementators will need to transfor
J.D. Falk wrote:
> Charles Lindsey wrote:
>
>> All of them are a proper subject of discussion, should this WG decide to
>> embark on such a BCP (and the misunderstandings repeatedly displayed here
>> seem to suggest that something of the sort is needed).
>
> Agreed, except for one thing: unt
On 10/15/2009 01:02 PM, J.D. Falk wrote:
> Charles Lindsey wrote:
>
>> All of them are a proper subject of discussion, should this WG decide to
>> embark on such a BCP (and the misunderstandings repeatedly displayed here
>> seem to suggest that something of the sort is needed).
>
> Agreed, except f
Charles Lindsey wrote:
> All of them are a proper subject of discussion, should this WG decide to
> embark on such a BCP (and the misunderstandings repeatedly displayed here
> seem to suggest that something of the sort is needed).
Agreed, except for one thing: until there's a larger set of us
On Wed, 14 Oct 2009 13:31:48 +0100, hector
wrote:
> Charles Lindsey wrote:
>
>>> But what [if] its not there?DKIM=DISCARDABLE provides a Domain
>>> Policy that mail must be signed and valid.
>>
>> If a valid signature is absent, then indeed the listadmin should discard
>> it (maybe even wit
On Tuesday 13 October 2009 20:54:40 Charles Lindsey wrote:
> On Tue, 13 Oct 2009 02:24:56 +0100, hector
>
> wrote:
> > The deployment guide section 6.5 writes:
> >
> >Any forwarder that modifies messages in ways that will break
> >preexisting DKIM signatures SHOULD always sign its forward
John Levine wrote:
>> A more interesting case to consider is acm.org style forwarders,
>> where the forwarder is, in many ways, the final destination, and where
>> the address at the forwarder is "owned" by the final recipient, and
>> where they will likely ask for transactional mail of the sort
>A more interesting case to consider is acm.org style forwarders,
>where the forwarder is, in many ways, the final destination, and where
>the address at the forwarder is "owned" by the final recipient, and
>where they will likely ask for transactional mail of the sort that
>senders might consider
Lets please keep the focus:
Section 6.1 and 7.4.1 describe a ADSP standard.
Section 6.5 describes a forwarding signing semantics that conflicts
with 6.1 and 7.4.1.
This is not a matter of one spec predating another. The deployment
guide attempt to merge the suite of DKIM technologies.
Under I
On Oct 14, 2009, at 2:32 AM, Charles Lindsey wrote:
>
> If a valid signature is absent, then indeed the listadmin should
> discard
> it (maybe even with 'ALL'). But the case of most interest is when the
> message arrives with a valid signature. In that case, the listadmin
> should
> do his bes
Charles Lindsey wrote:
>> But what [if] its not there?DKIM=DISCARDABLE provides a Domain
>> Policy that mail must be signed and valid.
>
> If a valid signature is absent, then indeed the listadmin should discard
> it (maybe even with 'ALL'). But the case of most interest is when the
> mes
--On 14 October 2009 10:32:32 +0100 Charles Lindsey
wrote:
> On Tue, 13 Oct 2009 22:27:52 +0100, hector
> wrote:
>
>> Charles Lindsey wrote:
>>
>>> On Tue, 13 Oct 2009 02:24:56 +0100, hector
>>>
>>> wrote:
>>>
The deployment guide section 6.5 writes:
Any forwarder that mod
On Tue, 13 Oct 2009 22:27:52 +0100, hector
wrote:
> Charles Lindsey wrote:
>
>> On Tue, 13 Oct 2009 02:24:56 +0100, hector
>>
>> wrote:
>>
>>> The deployment guide section 6.5 writes:
>>>
>>>Any forwarder that modifies messages in ways that will break
>>>preexisting DKIM signatures S
Charles Lindsey wrote:
> On Tue, 13 Oct 2009 02:24:56 +0100, hector
> wrote:
>
>> The deployment guide section 6.5 writes:
>>
>>Any forwarder that modifies messages in ways that will break
>>preexisting DKIM signatures SHOULD always sign its forwarded
>>messages.
>
> But it should
On Tue, 13 Oct 2009 02:24:56 +0100, hector
wrote:
> The deployment guide section 6.5 writes:
>
>Any forwarder that modifies messages in ways that will break
>preexisting DKIM signatures SHOULD always sign its forwarded
>messages.
But it should in addition say that it SHOULD also ad
The deployment guide section 6.5 writes:
Any forwarder that modifies messages in ways that will break
preexisting DKIM signatures SHOULD always sign its forwarded
messages.
However, there is no implication about forwarder signing restrictions
in section 6.5 which is possible in section
39 matches
Mail list logo
