Re: Last Call: draft-ietf-opes-smtp-security (Integrity, privacy and security in OPES for SMTP) to Informational RFC

[Frank Ellermann <[e-mail]>]

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's no problem.

It would be bad if OPES removes or quarantines critical MIME parts
needed for a verifier behind OPES.  Or if it manipulates parts of the
header required for DKIM.  Probably an obvious "don't do that", but
it's less obvious if something behind OPES (e.g. the MDA) decides to
forward or resend the message to a 3rd party.  DKIM is designed to
survive 1123 5.3.6(a) scenarios.

For some purposes OPES has to be as near to the border MX as possible,
ideally allowing to reject the mail before it's accepted.  For other
purposes it has to be as near to the MDA as possible, after it's clear
that the mail is not forwarded to a 3rd party.  That's a conflict.

>> 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.

I interpreted that paragraph as "reject (or if that's too late bounce)"
with instructions to the originator how to bypasss OPES.  And that's
in essence the same as C/R.

> I have no comment on whether this is "net abuse"

A bounce to an unverified (no SPF PASS or similar) Return-Path most
probably hits innocent bystanders.  That's unsolicited bulk e-mail,
the "bulk" part being that it's from a bot, not from a human sender,
and some inluding me consider UBE as spam, i.e. net abuse.

> you could easily see the mailman spam quarantine system under this
> model.

Mailman is behind all spam protection systems, DNSBLs, SPF, SA, OPES,
SIEVE, and what else.  It has a decent chance that most crap including
bogus Return-Paths is already filtered before it sends any inquiries
to the envelope sender (as specified in RFC 3834).  But OPES isn't
behind the filters, it is (a part of) the filters.

> Can Frank clarify?

See above, I wasn't talking about "bypass" actions triggered by the
recipient (maybe talking to the sender how to do this), but about any
"bypass" proposal in NDRs to forged envelope senders.

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 ?

Frank



_______________________________________________
Ietf mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf