duplicate suppression, sieve, loops, redirect and lost email

[Ragnar Sundblad]

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

> 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)?

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

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

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

Regards,

/ragge