ietf-smtp
[Top] [All Lists]

Re: 2821bis/ter and procedures (was: Re: retry question)

2008-08-08 10:02:25

On Fri, 8 Aug 2008, ned+ietf-smtp(_at_)mrochek(_dot_)com wrote:

I should also point out that if there are no valid recipients the
client probably sohuld not have bothered to send the message.

The server should probably have rejected the DATA command.

My take FWIW, is that none should be retried because the data is
rejected (probably based on content analysis e.g. spam or
virus). If the data response were a 450, a+b+c should be retried.

Yep, that's my (revised) assessment as well.

John's example is actually a perfect illustration of the context for my
original question. The server in question was using 450 replies to RCPT in
order to get separate deliveries of the same message for recipients with
different content filter settings. That is,

  MAIL FROM:<a>
  250 ok
  RCPT TO:<b>
  250 ok

The server notes that user B has aggressive content filtering settings.

  RCPT TO:<c>
  450 try later

The server sees that user C has lenient content filtering settings and
asks the client to try delivering the message to C later.

  RCPT TO:<d>
  550 no such user
  DATA
  354 go ahead
  blah blah
  .
  554 ugh

The message fails to pass B's filter settings, but it would have passed
C's settings. The server expects the client to interpret the post-data
rejection as a failure for recipient A only.

I don't recommend this kind of setup because I get the heebie-jeebies when
I contemplate the possible interoperability problems. Richard's and Ned's
comments above confirm my fears.

There are other places in which retry logic is underspecified, e.g. should
a client retry other MXs immediately or after a cooling-off period? Does
the answer depend on whether there's one MX records with multiple A
records, or multiple MX records at the same priority, or multiple MX
records with differing priorities? Implementers have come up with
different answers.

So I think that it would be useful to pin this down more precisely, both
for full clients and queueless clients. (Should message submission clients
handle errors like queueless clients even when they have queues?) However
I'm not very confident that we could get any useful consensus.

Tony.
-- 
f.anthony.n.finch  <dot(_at_)dotat(_dot_)at>  http://dotat.at/
CROMARTY FORTH TYNE: NORTH 4 OR 5, BACKING SOUTH 5 TO 7 LATER. SLIGHT OR
MODERATE. RAIN LATER. MODERATE OR GOOD, OCCASIONALLY POOR LATER.