Re: Working Group Last Call for draft-ietf-sieve-refuse-reject-00.txt

["Mark E. Mallett" <[e-mail]>]

On Tue, Aug 23, 2005 at 12:21:39PM -0700, Matthew Elvey wrote:
> No, that doesn't address my concern from a previous email:
> 
> On 8/19/05 2:18 PM, Matthew Elvey sent forth electrons to convey:
> >...[If] a Sieve script running on Dest  encounters a 'refuse', and 
> >sends a 550 to Relay 2, if Relay 2 then generates a bounce, instead of 
> >sending a 550 to MSA, then Dest MUST NOT be considered compliant with 
> >'refuse'. 
> >   +------------+                                    +-----------+
> >   | Originator |                                    | Recipient |
> >   +-----+------+                                    +-----------+
> >         |                                                 ^
> >         |                    Internet                     |
> >         |                    ___^___                      |
> >         V                   /       \                     |
> >     +---------+    +--------+       +---------+      +----+----+
> >     |         |    |        |       |         |      |         |
> >     | Source  +--->| MSA    +------>|  Relay2 +----> |  Dest   |
> >     |         |    |        |       |         |      |         |
> >     +----+----+    +--------+       +---------+      +---------+
> >
> >                                 \_________Destination_AU__________/
> >
> >
> That's why we need something like "between Administrative Units" of 
> "over the open Internet".

Yeah, I'd been kind of stewing on that for a while :-)

I think there's some schizophrenia in this discussion as relates to
refuse compliance.  There's one view of compliance that you get when you
focus on any given piece, and another when you combine that piece with
other pieces into a system.  To me, the idea is to make the pieces
compliant, and build compliant systems out of it.  Thus the spec should
say how to make compliant pieces, probably with a discussion about how the
pieces fit into the overall mail system.

If a Sieve implementation exists only in a tool that implements LMTP,
and it does indeed generate a 5xx LMTP response from a refuse verb, then
that specific tool could be viewed as refuse-compliant.  If that tool is
being called by some other program that delivers messages that are
already queued (as LMTP is described in rfc2033 as doing), then that
queue-running tool will probably generate a bounce response, and you
then have system that doesn't implement refuse correctly even if though
the Sieve implementation does.

On the other hand if the LMTP tool is being called by an MTA that's
engaged in an SMTP dialog, and the LMTP's 5xx response results in a
synchronous 5xx SMTP response by the MTA, then the system that combines
the MTA and LMTP tool is refuse-compliant.  However if then that MTA is
part of a larger email system that doesn't convey that result
synchronously, that larger system is no longer compliant with refuse.

Now: is the Sieve implementation correct, even though bounce messages
are generated?  I say yes it is, because it is correctly conveying the
result of the "refuse" action.  The spec should be about correct Sieve
implementations regardless of their place in the architecture.

This is at least one of the things that I am getting at when I say that
focusing on LMTP or SMTP or "over the internet" are all too specific.
It's not important that an implemenation uses LMTP or SMTP to give a 5xx
result, or uses a command line interface and exit with a status code
that indicates refusal, or anything else.  It's important only that that
specific implementation (no matter where or what it is) implement and
report refuse in some way.  That implementation can then be used as part
of some larger system implementation which then has a chance of itself
implementing refuse correctly.  And so on.

IMHO, as always.

mm