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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf