ietf-mta-filters
[Top] [All Lists]

Re: draft-ietf-sieve-refuse-reject-07.txt

2008-06-19 13:00:19

This is how a conforming system implementation would work:

Step 1) SMTP client connects to receiving system, which consists of an ingress MTA sitting on the Internet in front of (and protecting) an MDA (store) with which it communicates over LMTP. The system (the MDA in particular) contains and processes Sieve scripts.

Step 2) SMTP client continues the SMTP conversation to the point that the system receives a message to one recipient and the character sequence "<CRLF>.<CRLF>". (See 4.1.1.4 DATA (DATA) of RFC 2821)

Step 3) The system does NOT need to IMMEDIATELY reply, instead, it may perform some processing, as RFC 2821 indicates. RFC 2821 says specifically that the SMTP client SHOULD wait a minimum of at least 10 minutes for the "250 OK" reply. This processing should include:

Step 4) The MTA immediately connects to the MDA and attempts to pass on the message. If the MDA decides to 'ereject' the message, the MTA will pass along the message to the SMTP client by sending a failure message, instead of "250 OK".

I believe all or at least nearly all multi-component implementations can and should work this way.

Note: if the MTA tries to contact the MDA in step 4 and is unsuccessful, it can try again several times; it should have at least 10 minutes (that's a lot of milliseconds) to get back to the SMTP client. And even at that point, it can send a 4xx, and try again when the SMTP client tries again.

In other words, a conforming system cannot include an MTA that immediately accepts such a message, passes it to an MDA that processes it with a sieve script that decides to ereject it, and have that MDA blithely send out a DSN.


On 6/18/08 5:21 PM, Ned Freed wrote:
<did it again.  :( >
On 5/29/08 9:22 AM, Ned Freed wrote:
> <Ned quote me but didn't include a quotation line; please do so in
> future, Ned.>:

>> And I'm not clear why this is needed; I don't think it's the case:
>> (However, the LMTP client may then have no choice
>>     but to generate a DSN to report the error, which may result in
>>     blowback.)
>> Where it appears to be the case, the LMTP client may just need to be
>> fixed.
>
> Fixed how? Suppose the LMTP client is on an ingress MTA. Messages come
> in from the Internet using SMTP and are then sent on using LMTP to affect
> final delivery.

I suspected you'd be bringing this case up again.
It needs to be fixed if it accepts the message before it has determined
whether it should receive it.

But that's operating at the SMTP level, not the LMTP level. And the only
way to enforce that is to not allow LMTP server-side implementation of
ereject.

But if that's the consensus for what we want to do (and while I personally don't object I've seen no consensus for such a change) then we need to come out and say that explicitly, not try and eliminate the case by first including LMTP as a possible place for ereject to be used but then trying to Venn-diagram it out of existance with a bunch of complex overlapping requirements LMTP cannot
meet.

The approach you're advocating is a sure-fire recipe for confused implementors and broken implementations.

(This discussion has already been hashed out; it's a bit frustrating to
have to go through it again.)

Well, that discussion apparently did not result in even a mention being added of the likely consequences of LMTP server-side use of rereject, so apparently
it didn't stick.

> Suppose the Sieve implementation is operating as part of the LMTP
> server. (This
> isn't how I'd ever do it, but it is nevertheless a perfectly legitimate
> implementation option.) A message comes in via SMTP and is queued for
> delivery. The LMTP client sends it to the LMTP server, which then runs
> the Sieve which then does an ereject. This is then translated into a
> 550 LMTP response.
>
> What is the MTA supposed to do now?

You're asking me what to do once you've painted yourself into a corner.
My answer is: DON'T paint yourself into a corner.

And the only way to avoid the corner (in the ereject case at least) is not
to operate at the LMTP server level.
Nope; see the 4 steps above.

More generally, however, there's no way to avoid this case. We go to a lot of trouble to try and detect things like over quota conditions so we can reject at the SMTP level. But this depends on back-channel communication to our MTA from our store. If our MTA is used with someone else's LMTP server - as it sometimes
is - we have no way to perform a useful check at the SMTP level.
If you'd care to explain why an implementation can't conform to the 4 steps I explain, I'm all ears; I have yet to hear such an explanation. (Other than the claim that the system isn't a system; the MTA and MDA are independent.) My response is that if someone insists on looking at things that way, that's their right, but then their MDA should not be considered conforming.

Again, I've done nothing but argue with you about the difficulty and merits of conforming to proposed requirements. I should expressed that differently, and for that I apologize: I could have instead said that changing an existing implementation to conform could be difficult and time consuming; I have said so before. I'm sorry that you feel attacked, but I have not attacked you.




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