duplicate suppression, sieve, loops, redirect and lost email

[Ken Murchison]

Ragnar Sundblad wrote:
> 
> --On den 29 augusti 2002 10:53 -0400 Ken Murchison <ken at oceana.com> wrote:
> 
> > I'm not about to rewrite code because of user ignorance.
> 
> Sure, but here email is actually lost because of assumptions

What assumptions are those.  The system merely does what the user asked,
but also prevents a mail loop as stipulated by RFC 3028.


> the system is making combined with a user mistake, which I
> think is something different than just plain misuse due to
> ignorance. Such traps really should be avoided by all means.

This still sounds like we're trying to protect the users from
themselves.  We could spend forever trying to do this, and never get
anything done.


> > If the user doesn't understand how Sieve works, then they
> > shouldn't be writing their own scripts by hand.
> 
> A tool wouldn't easily detect this either. How could it reliably
> find out all possible ways for a email to get looped back,
> including a forwarding loop with another system (a maybe more
> common user error than forwarding to oneself)?

It can't, but it _should_ be capable of detecting that the user is
trying to redirect directly to themselves and make it a 'keep' instead. 
The bottom line is that the user is using the wrong action to keep the
message.


> > In no way does a redirecting a message to myself make any sense,
> > nor does it imply that it would even actually get delivered.
> 
> Agreed and agreed, but to the second one - I most strongly
> believe it should get bounced, for example due to too many hops,
> not ever dropped.
> 
> As RFC 2821, 6.1, puts it:
> "  When the receiver-SMTP accepts a piece of mail (by sending a "250 OK"
>    message in response to DATA), it is accepting responsibility for
>    delivering or relaying the message.  It must take this responsibility
>    seriously.  It MUST NOT lose the message for frivolous reasons, such
>    as because the host later crashes or because of a predictable
>    resource shortage.
> 
>    If there is a delivery failure after acceptance of a message, the
>    receiver-SMTP MUST formulate and mail a notification message.
> "
> ...
> 
> You could argue that this problem is not "frivolous", and you
> could maybe argue that cyrus/sieve has "delivered" as well as
> you could say that cyrus/sieve actually is a part of the smtp
> system when you redirect.
> My point is that this states the general idea of how things
> should work, and if there should be any point in having this
> functionality in the transit network, the end systems must
> behave at least as "responsible".

I'd argue that the system has done its job, and the user's actions have
caused the mail to be lost.

> 
> > The redirect code will not redirect the same message to the same
> > recipient more than once (with or without duplicate suppression on).
> 
> I see, thanks for that information!
> 
> > I think it already does this.  The duplicate_check() code uses both the
> > msg-id and the destination mailbox as the key into the database.
> 
> Indeed it does! I was absolutely sure it did not. Sorry.
> 
> Thanks for straightening those things out for me. With all
> this information kept already I think there just must be a
> feasible solution to this.
> 
> I currently think that what is needed is that if the message
> is not in any mailbox for the addressee, no kind of duplicate
> suppression or sieve redirection suppression should be done,
> since there is no way to tell if this is a duplicate or indeed
> the single original message that we happen to have seen before.
> But this could very well be wrong, thoughts are welcome.

Checking all of the user's mailboxes for a message-id would be very
expensive.


> Do you, or anyone else, have any ideas of how to solve this?
> (They would probably be far better than mine anyway.)

My idea (and from one of the guys at CMU) is to educate the user. 
Otherwise, I don't know what the "right" thing to do is.  How much
intelligence are we supposed to put into the system?

I too am curious to hear any suggestions.

Ken
-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp