> > 'Sieve Email Filtering: Reject and Extended Reject Extensions '
> > <draft-ietf-sieve-refuse-reject-07.txt> as a Proposed Standard
> The draft wants to "update" RFC 3028, but this RFC was obsoleted
> by RFC 5228. Good riddance wrt 'reject', reviving this "CANSPAM"
> recipe appears to be a bad idea.
I, OTOH, am a lot more comfortable exaplining how to do something correctly
than I am not telling people anything and having them go it alone and get it
wrong.
> LMTP happens after final SMTP delivery.
If it does, then you're dealing with a deeply broken implementation. If LMTP is
used it *is* the final delivery step.
> At this point it is not
> more possible to cause a "real" SMTP reject while talking with an
> alleged sender.
That's an issue quite separate from when final delivery occurs. The problem
here is that once the SMTP server has accepted the message it is no longer
possible to turn back the clock and reject it at the SMTP level. Final delivery
isn't really relevent.
Now, one way to partially address this in an implementation is to overlap the
SMTP and LMTP sessions. But even this cannot possbly cover all cases - suppose
there are multiple recipients and the LMTP server returns a mixture of success
and failure responses after the final dot. The LMTP client/SMTP server then has
no choice but to return a success in the session and subsequently send back
DSNs.
> That is the main issue in this draft. I'm not
> yet convinced that an LMTP "downref" is appropriate or necessary.
Finally, a point we can agree on. I have real misgivings about the way this
draft discusses LMTP server-side implementations, for several reasons. Besides
the previously mentioned issue that there are cases which unavoidably cause
DSNs to be sent no matter how clever the client is, a server has no way of
knowing that the client talking to it is one of these clever ones anyway. (And
it certainly cannot count on it.)
I believe we'd be better off if most of the discussion of server-side LMTP
implementation was simply removed from this document, perhaps to be replaced
with a statement that ereject cannot be properly implemented in this context
and reject is problematic since it cannot be promoted to an SMTP-level failure.
However, the consensus of the group was to keep this in spite of my misgivings.
But I certainly have no problem if the consensus changes during last call to
agree with me ;-)
Ned
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
