ietf-openproxy
[Top] [All Lists]

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

2005-01-22 11:59:41

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  <dot(_at_)dotat(_dot_)at>  http://dotat.at/
CULLERCOATS: GALE OR SEVERE GALE FORCE NORTHERLY WINDS SLOWLY DECREASING.