RE: [draft-ietf-opes-smtp-use-cases-01]

On Thu, 13 Jan 2005, Martin Stecher wrote:
>
>  1. MTA receives email, i.e. it receives SMTP commands and vectors them
>     out to the callout server
>        a) callout server modified the command value: MTA will treat the
>           modified value as if it received it that way from its SMTP peer
>        b) callout server returns an SMTP error-reply: MTA will send that
>           error code to its SMTP peer
>
>  2. MTA sends email, i.e. generates SMTP commands and vectors them out
>     to the callout server
>        a) callout server modified the command value: MTA will send
>           modified command to its SMTP peer
>        b) callout server returns an SMTP error-reply: MTA does NOT send
>           the command to its SMTP peer but treats the error as if it
>           received it from the SMTP peer

Following on from what jfcm said, I can't see any use cases in the
existing draft which fall into the second pair of these categories, and
I'm not sure that anything out in the real world falls into them either.
Current email filtering systems either operate at SMTP time (e.g. the
Sendmail milter system, or Exim's access control lists) or they operate on
messages after reception (e.g. MailScanner) either on the MTA's queue or
by being handed from the MTA to the filter and back again.

Tony.
-- 
f.a.n.finch  <[email protected]>  http://dotat.at/
CULLERCOATS: GALE OR SEVERE GALE FORCE NORTHERLY WINDS SLOWLY DECREASING.