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.
|
|