Michael Thomas wrote:
Such as a bounce?
I thought that a bounce was a MAIL FROM: ?
Yes, of course this could be also another auto-reply.
I don't recall seeing a null 822 From:
That would be a clear syntax error, and I think one
technical reason why DKIM uses From is that it's
guaranteed
Hector Santos wrote:
The deployment guide specifically states:
Unless a scheme can correlate the DKIM signature with
accreditation or reputation data, the presence of a DKIM
signature SHOULD be ignored.
And that implies even a VALID signature. So the DEPLOYMENT
draft changes
Frank Ellermann wrote:
Michael Thomas wrote:
Such as a bounce?
I thought that a bounce was a MAIL FROM: ?
Yes, of course this could be also another auto-reply.
I don't recall seeing a null 822 From:
That would be a clear syntax error, and I think one
technical reason why DKIM uses
Eric Allman and I have been discussing a larger change to the SSP
specification that we believe addresses a number of the issues that have
been raised.
The biggest change is the separation of the SSP function into a
checker, that retrieves the SSP record/records relevant to a given
message,
Hector lamented:
Its unfortunate that it has nothing to do with technical reasons but
the
powers that are pushing reputations instead. The fact is, Dave's
never cared for SSP and its spelled out in his deployment guide, and
the other guy pushing his reputation service has no room for SSP
John Levine wrote:
Well, gee. What if there are two From: lines? Three From: lines? A
From: line with two addresses but no Sender:? A From: line with two
addresses, one of which has no @ sign?
And if you quickly skip down to South Beach, you will find Fidel Castro
sun-bathing smoking a
John Levine wrote:
Frank, you're (inadvertently?) bringing up exactly the kind of
corner cases that I was trying to raise so that SSP implementations
have the same behavior in their presence. It may be that all we
practically need to do is refer to 2822 and say that if the From:
field is
At 4:03 PM -0800 1/25/08, Jim Fenton wrote:
Eric Allman and I have been discussing a larger change to the SSP
specification that we believe addresses a number of the issues that
have been raised.
The biggest change is the separation of the SSP function into a
checker, that retrieves the SSP
When I pointed out that the first from rule enabled a trivial end
run around SSP, by using a real first address and a forged second
address that is likely to be visible in MUAs, I naively assumed that
it would be obvious to everyone that any rule other than checking all
the addresses would
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Hector Santos
Sent: Friday, January 25, 2008 2:28 PM
To: Frank Ellermann
Cc: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] Re: SSP vs. reputation
Frank,
snip
It will not make sense for me to add
On Jan 25, 2008 12:08 PM, [EMAIL PROTECTED] wrote:
Charles,
Are you not making the assumption that implementaors may check SSP before
checking dkim? A quick SSP lookup first returning a strict against a third
party dkim signed mail may be processed differently than a SSP relaxed
Thanks,
Mark Delany wrote:
On Jan 24, 2008, at 6:14 PM, Hector Santos wrote:
But to disagree with you, I voted +1 precisely for technical reasons. I
want a simple solution that non-WG-specialists can grok. I don't think
we have that today.
Well Mark, I'm surprise if you really mean that. If you
Charles,
Are you not making the assumption that implementaors may check SSP before
checking dkim? A quick SSP lookup first returning a strict against a third
party dkim signed mail may be processed differently than a SSP relaxed
Thanks,
Bill Oxley
Messaging Engineer
Cox Communications
Frank Ellermann wrote:
Michael Thomas wrote:
I'm aware that this is not legal, but these sort of things
happen in the real world, and are the kind of things that
cause interoperability and/or deployment issues. Since SSP
is a security protocol, we can pretty much be guaranteed that
somebody
On Thu, 24 Jan 2008 19:54:00 -, Jim Fenton [EMAIL PROTECTED] wrote:
My concern has to do with whether the SSP of the other From (author)
domains has to be considered as well. Just as the point has been made
that it's not proper to handle this case by arbitrarily picking the
first From
On Jan 24, 2008, at 6:14 PM, Hector Santos wrote:
Mark Delany wrote:
On Jan 24, 2008, at 8:37 AM, Wietse Venema wrote:
Summary of proposal:
All text that causes SSP to be applied to an already-signed
message
needs to be removed.
I would take this further: remove all text that says when
Frank,
The point is that in a new level of DKIM/SSP operations, these things
would be a natural part of the checking Frank.
It may not jive with some aspects of the current relaxed nature of
internet email, but that is why we have such a high rate of fraud too,
the unverified relaxed nature
Michael Thomas wrote:
I'm aware that this is not legal, but these sort of things
happen in the real world, and are the kind of things that
cause interoperability and/or deployment issues. Since SSP
is a security protocol, we can pretty much be guaranteed that
somebody will eventually start
Steve Atkins wrote:
ISPs aren't going to reclassify a message from should be rejected to
deliver to inbox on a whim.
Sure they are.
ISPs are responsible to their customers, not the senders. They should,
and usually will, do what will make their customers happy.
You replied out of context.
Hector Santos wrote:
Sent: Friday, January 25, 2008 12:55 PM
To: Frank Ellermann
Cc: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] SSP vs. reputation
Oh I see, you are redirecting the original mail to someone
else as if it was new.
You are not using the FORWARDING features of the MUA.
20 matches
Mail list logo
