The IESG wrote:
> as an Informational RFC
The "bypass" construct apparently includes what's also known as
"challenge response scheme". If that's the case it's net abuse,
unless the challenge is guaranteed to be sent to the originator.
The only relevant case where that's guaranteed I'm aware o
Frank,
I'd have to go further than what you wrote. I believe the document
should explicitly discuss interactions with DKIM, as that document is in
front of the IESG at this time for approval as a Proposed Standard.
Many modifications to a message will invalidate a DKIM signature. It
may be
At 9:21 AM +0100 1/7/07, Eliot Lear wrote:
>Frank,
>
>I'd have to go further than what you wrote. I believe the document should
>explicitly discuss interactions with DKIM, as that document is in front of the
>IESG at this time for approval as a Proposed Standard. Many modifications to
>a messa
Ted Hardie wrote:
> I don't think adding explicit interactions with DKIM is appropriate
> for this document,
If OPES sees the complete message (header + body) it could be used as
signer (conceptually somewhere between MSA and mailout) or verifier
(between MX and MDA, if it has DNS access). That'
Hi Ted,
I don't think adding explicit interactions with DKIM is appropriate for this
document,
which is a high-level informational document on the set of problems of adapting
OPES (developed in a bidirectional model) to SMTP, which has very different
usage.
The reason I'm concerned is tha
At 4:59 PM +0100 1/10/07, Eliot Lear wrote:
>
>The reason I'm concerned is that any form of OPES might invalidate a DKIM
>signature. What can we say in a DKIM sense about OPES trace information?
Do you mean, should a DKIM server sign OPES trace information? The DKIM
base document says:
4. Se
Ted Hardie wrote:
At 4:59 PM +0100 1/10/07, Eliot Lear wrote:
The reason I'm concerned is that any form of OPES might invalidate a DKIM
signature. What can we say in a DKIM sense about OPES trace information?
Do you mean, should a DKIM server sign OPES trace information?
Maybe one of you
>
> I never got the OPES idea. Of course folks can do their A/V
> and SIEVE and SIQ (I-D.irtf-asrg-iar-howe-siq-03) businesss
> on a separate box, they can even outsource it, but they do
> this already without OPES.
> So what's the technical point of OPES wrt mail ?
>
OPES' technical point
Stechter,
Thanks for the followup.
Stecher,Martin wrote:
This will allow to create such a separate filter box that you mentioned
but have it negotiate with different proxies and gateways what kind of
protocol/data it can handle.
Given what you say at the end of this sentence, I assume this i
On Thu, 11 Jan 2007, Dave Crocker wrote:
>
> As has been clear for some time, the OPES topic is both important and
> difficult. That sort of combination always makes want to look for some
> history of exerience with ways to solve the current problem. In the case
> of OPES, I do not know of a quali
Tony Finch wrote:
If the current document is intended as a case analysis for a particular
application -- namely email -- to serve as *input* to the design of the OPES
architecture and protocols, then I do not see how the current document
achieves that.
I believe it's intended to fit the existi
Markus Hofmann wrote:
> The intend of publishing this document before dissolving the WG is to
> have the discussion on how the IAB considerations apply to OPES/SMTP
> written down, in case individual contributors might pick-up the
> OPES/SMTP work later on (although we don't have indication this m
Eliot Lear said...
I'd have to go further than what you wrote. I believe the document
should explicitly discuss interactions with DKIM, as that document is in
front of the IESG at this time for approval as a Proposed Standard.
Many modifications to a message will invalidate a DKIM signature.
On Fri, 2007-01-12 at 00:42 -0500, Barry Leiba wrote:
> Eliot Lear said...
> > I'd have to go further than what you wrote. I believe the document
> > should explicitly discuss interactions with DKIM, as that document is in
> > front of the IESG at this time for approval as a Proposed Standard.
Markus Hofmann wrote:
The intend of publishing this document before dissolving the WG is to
have the discussion on how the IAB considerations apply to OPES/SMTP
written down, in case individual contributors might pick-up the
OPES/SMTP work later on (although we don't have indication this migh
Dave,
Thank you. This is extremely helpful.
I suggest that the document have something like your above text added to
the Introduction.
Agreed, good suggestion. We'll add some words in.
Thanks,
Markus
___
Ietf mailing list
Ietf@ietf.org
https:/
16 matches
Mail list logo
