ietf-smtp
[Top] [All Lists]

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

2008-08-08 19:38:19

At 09:32 AM 8/8/2008, Tony Finch wrote:
The server should probably have rejected the DATA command.

The 554 does not mean "no valid recipients" in this case as there was a 250 in the RCPT TO phase.

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 take it you mean b.

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.

The problem is that we are trying to do per-recipient content filtering. That doesn't fit in the current model which is why we might use the 450. There was some discussion about a SMTP extension to allow per-recipient content filtering.

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.

There are different retry strategies. Sending hosts should be careful not to overwhelm receivers by doing frequent retries. It's not as easy to define a "standard" retry logic for the cases mentioned above.

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.

I think that we should separate message submission clients from MTAs as they are each set for a different purpose. Given the diverse nature of SMTP, it would be difficult to pin the behavior down more precisely.

Regards,
-sm
<Prev in Thread] Current Thread [Next in Thread>