[Top] [All Lists]

Re: Overview of per-recipient data reply proposals

2007-02-04 20:09:04

On 2/4/2007 6:01 PM, Peter J. Holzer wrote:
On 2007-02-04 16:11:51 -0500, Eric A. Hall wrote:

Many of us are using tools that inspect the message body before we decide
to bother with delivery, so this is an important filter.

I'm not sure I understand. All of the proposals allow content-inspection
according to per-recipient rules before delivery.

There are two points where content inspection currently occurs in the
wild: one is inside the MTA, and the other is per-recipient analysis that
is usually handled during delivery agent handling (with DSNs being
generated on failure).

Models that only allow for content inspection in the delivery function
basically sacrifice the global inspection option. Yes it's possible to use
global rules and require the delivery process to fail every recipient, but
that's not very subtle nor is it particularly attractive.

point you make is that the deferral draft doesn't allow delivery to
start before the final reply, while with the LMTP model the message can
be delivered to a recipient as soon as content scanning for that
particular recipient is done.

Well yeah but allowing the data to be analyzed before the delivery
function is called obviates the need for that entirely.

Consider a spam-trap address that is third in the list of recipients--if
you only allow analysis at the delivery stage then it's basically too late
to do anything with it. Same with viruses. By combining delivery with
inspection you've basically said that we need to confirm successful
processing for each user individually, which is a huge waste.

Okay. This is handled in the DEFERRALS draft with the ability to simply
reject the message outright (in lieu of the "here come the deferred RCPT
responses" code), prior to delivery function being called, and without
enumerating each of the recipients.

|  6.2.    The 353 Response Code
|    If the message is accepted or refused by every recipient, the 353
|    response code and the subsequent responses MAY be substituted with
|    a single response code which reflects the global outcome. For
|    example, if all of the recipients accepted the email message, then
|    a single 250 response code MAY be returned in lieu of the 353
|    response code, the per-recipient response codes, and the final
|    response code. See section 6.4 for considerations about these
|    final response codes.

I don't know about the other proposals (simply surfacing LMTP would not,
but I haven't studied the others), and I think it would be a useful
data-point for comparison purposes.

Eric A. Hall                              
Internet Core Protocols