On 2013-02-06 at 10:53 -0800, Todd Lyons wrote:
> .
> 353 PRDR content analysis beginning
> 550 PRDR R=<toddreject@???> refusal
> 450 PRDR R=<todddefer@???> temporary refusal
> 250 PRDR R=<todd@???> acceptance
> 550 Detected dedicated spamware generated email
> It seems like the 250 PRDR response should not get issued until after
> the message passes the actual DATA acl, no? You can't issue a 250 and
> then turn around and reject it AFAIK.
>
> ...5 minutes later...
>
> WRONG. According to the draft:
>
> 4.5.3. The Final Response Code
>
> After the server has transmitted all of the recipient-specific
> response lines, a final response that indicates whether or not
> the server will accept responsibility for the email message as
> a whole MUST be returned.j
I think the interpretation you are placing upon that is not the
interpretation expected, as evidenced by the example in section 5.1 of
partial failure.
Do remember that you're working from a _first_ draft of an RFC, so
it's not as polished on these issues as we'd normally expect from a
modern full RFC.
----------------------------8< cut here >8------------------------------
5.1. One Failure, One Success
The following dialog illustrates a message with two recipients,
one of which refuses the content, the other of which accepts:
[...]
C: DATA
S: 354 go ahead
C: <sends data>
C: <crlf>.<crlf>
S: 353 content analysis has started
S: 550 5.6.0 fighter@??? refuses the content
S: 250 2.1.5 lover@??? accepts the content
S: 250 data accepted by some recipients
Since the message was acceptable to one of the recipients, and
since the server is able to accept the message for subsequent
processing, the final response indicates success. At this point,
the SMTP client would need to clear the message from its queue,
and then generate a disposition or error message on behalf of the
failing recipient.
----------------------------8< cut here >8------------------------------
So the 250 means that the message was accepted for some recipient, the
message identified by that Message-ID header now exists on the receiving
server, but only for those recipients that were individually accepted by
PRDR. The sender has to generate bounces for the other recipients.
So, if _any_ of the recipients gave a 250 response, then overall a 250
response must be given.
Further, I'd expect that to be the case so that the local system's
queue-id (Exim $message_id) can be given in the final 250 response, as
per normal, so that the sender's logs can record that queue-id, for
correlation in tracing message flow as folks try to debug what happened
to a particular mail.
If Exim sends mail with PRDR and the receiving system takes it for one
recipient, what ends up in the sending-Exim's log-lines in the C="..."
field? Without PRDR, it's the one 250 line, which will contain the
queue-id. With PRDR, which of the two makes it in, and why? Or both?
It seems that both make some sense, but we definitely do need the final
response, to get the queue-id.
-Phil
