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

[Matthew Elvey <[e-mail]>]

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.>:
>
>
>> I disagree.  There is a loophole for an implementer to decide that 
>> what he or
>> she feels is preferred is to not bother fulfilling this requirement. 
>> It needs
>> to be closed.
>
> Then you really need to provide better evidence that such a loophole 
> exists -
> because I'm not seeing it.
That's funny.  You do see it.  You just don't realize it.  You drove the 
LMTP truck through the loophole!! (see LMTP discussion below)  My latest 
draft doesn't have the loophole that you've insisted LMTP 
implementations should be able to drive through!
>> I also support the addition of the text Ned proposed:
>
>> "the risk that these actions will generate blowback spam are
>> minimized but cannot be eliminated completely even in the case of 
>> ereject, so
>> caution is advised when using these actions to deal with messages 
>> determined to
>> be spam."
>
>> It can go at the end of 2.1.2.
>
> 2.1.2 discusses sending DSNs and is therefore entirely the wrong place 
> for
> this. It belongs at the end of 2.1.1, the section talking about 
> SMTP/LMTP level
> rejects.
Agreed.
>
>
>> and I don't see why
>>     Script generators SHOULD ensure that a rejection action being
>> shouldn't be
>>     Script generators MUST ensure that a rejection action being
>
> This cannot be a MUST, if for no other reason that such generators could
> easily be operating in an MUA content where ereject is not available.
Agreed.
>
>> also, let's change
>>     using the ereject action, as it is more suitable for such 
>> rejections.
>> to
>>     using the ereject action, as reject is unsuitable for such 
>> rejections.
>
> The problem with such claims is that the bar they effectively set is so
> high ereject cannot meet them either. I'm therefore opposed to this as 
> well.
I don't understand what you're saying here. Can you put it another way?
>
>> also, let's change
>>     support protocol level rejection, e.g. an MUA, and MUST be available
>> to
>>     support protocol level rejection, i.e. an MUA, and MUST be available
>
> It is entirely possible for there to be critters in the email universe 
> that act
> at the UA level but which aren't thought of as UAs. So what you are doing
> actually weakens the requirement by making it sound like it only 
> applies to
> MUAs specifically.
Have you thought of an example you can provide?

>> I still strongly support requiring a change to the default behaviour,
>> and feel that there is reluctance to change the current behaviour for
>> what was presented as nothing more than an unwillingness to explain what
>> we all agreed were net good reasons for the change.
>
> I fail to see continuing to impugn the motives for the position I have 
> taken is
> in any way helpful here. But in the interests of keeping this civil 
> I'm not
> going to respond further. 
I've said that the justification is poor.  It's not about you; it's not 
ad hominem, so please don't paint it as such.  The point is that the 
evidence/argument provided against chaning the default behaviour is weak.
>
>> 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.
(This discussion has already been hashed out; it's a bit frustrating to 
have to go through it again.)

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

Do I sympathize with you for painting yourself in a corner?  Sure.  But 
if you insist on doing it in perpetuity, I don't.

Do the TCP or Ethernet specs say send data as fast as you please?  No; 
why should we say do what you please here just because there's a market 
for such harmful product? If you've written an ingress MTA to always 
accept mail before determining that the final delivery can be made, then 
you have reasons to paint yourself into a corner: laziness, defense of 
market niche, the system/software you've written works better that 
way...  Good enough reasons?  Not IMO.

> It has exactly two options available:
>
> (1) Silently discard the message.
> (2) Generate a DSN and send it to the MAIL FROM address.
>
> (1) is only appropriate if the MAIL FROM is emoty, NOTIFY=NEVER is in 
> effect,
> the MAIL FROM Is somehow known to be forged. That leaves generating a 
> DSN as the only viable alternative in most cases.
>
> Returning a 550 SMTP response is not possible for the simple reason 
> that the
> SMTP connection is long gone - in fact it could have taken place hours 
> or even
> days earlier.
> I will also note that the behavior of such an MTA, which not only 
> isn't the
> agent with the Sieve implementation, it likely will not even be aware 
> that
> Sieve is involved, is entirely out of scope for this working group. We 
> cannot
> impose requirements here even if we wanted to.
>
>> If there is indeed such a case, it needs to be specified.
>
> Specify what? 
Do what you did.
> The unfortunate reality is that once a message has been accepted
> by an ingress MTA the options for getting rid of it narrow down to 
> discarding it, with or without sending a notification.
> Now, I have long been a proponent of turning away as many messages as 
> possible
> while the connection is still there for reporting errors. But neither 
> this
> document nor this workging group are the places to make the case for 
> doing
> things this way.
>
>> Oh, and the acronyms MDA,  MTA and MUA are now used but not defined (as
>> Mail Delivery, Transfer and User Agents, respectively)
>> draft-crocker-email-arch-10.txt defines 'em, but it's been an I-D for as
>> long as this I-D, so I suggest we just spell 'em out on initial use.
>
> I agree the terms need to be defined but the right way to do is is by
> referencing the architecture document. The Sieve environment draft did 
> so and
> this has not proved to be a barrier to publication.
Ok.  Defined or just spelled out; either is fine with me.
>
>                 Ned



-Matthew