[Top] [All Lists]

deferred RCPT responses

2004-03-27 16:28:30

Rejecting mail during the session (as opposed to off-line, afte the mail
has been accepted) is very useful, in that it prevents the creation of
false bounces, pushes the queuing problem back to the spammers, scammers
and worm-riders, and so forth.

There is a problem with this approach, however, which is that some
messaging systems and/or networks have different policies for different
recipients -- different users have different thresholds or requirements.
However, it's currently imposible to reject a message for some while
accepting the same message for others (during the same SMTP session
anyway): they all get it or none of them do. In the former case you are
back to doing off-line rejects, and in the latter case you are swatting
flies with sledgehammers (and destroying the furniture in the process).

It seems to me that the right way to deal with this is to defer the
acceptance of each RCPT command, and then inform the final status after
the end-of-data sequence. For example:

  C:  RCPT: idiot(_at_)example(_dot_)net
  S:  310 maybe
  C:  RCPT: hardass(_at_)example(_dot_)net
  S:  310 maybe

  C:  DATA
  C:  [...]
  C:  <CRLF>.<CRLF>

  S:  550-hardass(_at_)example(_dot_)net doesn't like this stuff
  S:  250-idiot(_at_)example(_dot_)net enjoys pain
  S:  250 accepted

The problem with that approach is with varying post-DATA acceptance codes,
in that they contradict the expectation for common response codes in
multi-line answers.

Clearly, some kind of ESMTP extension could be built to wrap that up
appropriately, but the problem with using an ESMTP extension is that it
will never be used in those places where it would be most useful -- the
SMTP mailers in spamware.

Anybody have any thoughts on this subject, or is this only resolvable in
subsequent transfer protocols?

Eric A. Hall                              
Internet Core Protocols

<Prev in Thread] Current Thread [Next in Thread>