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 message will invalidate a DKIM signature. It may be possible for an OPES
>agent to resign, but there are implications there too that should be discussed.
>
>Eliot
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.
To tackle the the bypass question; the Bypass section says:
>3.2 Bypass in OPES/SMTP
>
> If a mail message was rejected or could not be delivered (and a NDR
> was sent), the originator of the message may want to bypass the OPES
> system that blocked the message.
>
> If the recipient of a message receives a mail with OPES trace
> information, he may want to receive a non-OPES version of the
> message. Although there is no direct in-band request from the
> recipient back to the OPES system, the recipient can contact the
> sender and ask her to send the message again and to add a bypass
> request for the OPES system.
Note that this implies that the receiver detects the use of OPES
by trace information. How the recipient could contact the sender
is left undefined here.
> An OPES system MAY also define out-of-band methods to request a
> bypass, for example a web interface or an email message sent to it
> that results in the creation of a white list entry for the sender/
> recipient pair. Examples for these out-of-band methods are email
> systems that keep a copy of the original email in a quarantaine queue
> and only send the recipient a block notification plus either a direct
> link, or a digest notification with the ability to retrieve the
> original message from quarantaine.
I assume that this is where Frank sees the potential for a challenge
response. I have no comment on whether this is "net abuse", but
you could easily see the mailman spam quarantine system under
this model. The spam checker puts the document in a quarantine
and one or more systems is used to prove that it out to get out.
This presumes, though, that the action is taken by the recipient,
not by the originator. I do not see where the challenge/response
to the originator fits here. Can Frank clarify?
> OPES MUST implement methods to request a bypass but there cannot be a
> guarantee that the bypass request will be approved. The security
> needs of the receiver or the receiver's network may demand that
> certain filters must not by bypassed (such as virus scanners for
> example). In general, the receiver should be able to configure a
> client centric OPES system, i.e. the receiver should be able to
> indicate if he/she wants to receive a non-OPES version if it is
> available.
>
> Bypass requests could be added to the mail message or within the SMTP
> dialog. Bypass request data added to the mail message cannot bypass
> OPES services that operate on other SMTP dialog commands, which are
> sent before the mail message has been received (such as RCPT
> commands).
Note that this high-level document does not propose any such protocol
mechanism.
> Bypass request data sent at the beginning of a SMTP dialog may not
> reach the OPES system if intermediate SMTP relays do not support
> those bypass request commands and don't forward that information.
You could theoretically model the DKIM verification as an OPES-like action,
and require that the DKIM provide the same sort of bypass functionality;
it already provides trace functionality in ways that meet the opes-smtp
limits. I don't think folks have done so so far, because they have not
seen the signer's actions as the actions of an intermediary. The action
of an MTA in potentially rejecting mail on the application of a policy does
seem to fall into the same problem space.
Ted
>
>Frank Ellermann wrote:
>>The IESG wrote:
>>
>>
>>><draft-ietf-opes-smtp-security-02.txt> 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 of is an
>>SPF PASS. Even in that case some originators might consider the
>>challenge as abusive, but at least it's not unsolicited, and they
>>can stop their communication attempts with such OPES receivers.
>>
>>But the general case is no SPF PASS, and then the challenge goes
>>most probably (near 90%) to innocent bystanders.
>>
>>Frank
>>
>>
>>
>>_______________________________________________
>>Ietf mailing list
>>Ietf@ietf.org
>>https://www1.ietf.org/mailman/listinfo/ietf
>>
>>
>
>_______________________________________________
>Ietf mailing list
>Ietf@ietf.org
>https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
