duplicate suppression, sieve, loops, redirect and lost email

Ragnar Sundblad ragge at nada.kth.se
Fri Aug 30 22:41:47 EDT 2002



--On den 30 augusti 2002 10:11 -0400 Ken Murchison <ken at oceana.com> wrote:

> What assumptions are those.

The assumption that just because you see a letter that looks
like one you have seen before, it must be a duplicate and can
be discarded. It may not be, it can very well be the very same
and single instance as has been seen before. You can not know
that it is a duplicate if you don't know there is another copy,
for example on local disk.

This is the base problem with both the redirect-to-self problem
and the mail-loop-with-more-than-one-server. Possibly others.

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

I guess you mean 4.3, "Implementations SHOULD take measures to
implement loop control, "... I have no idea what they ment when
they wrote this. How could a sieve script possible know?
This is perhaps applicable if you could redirect between
mailboxes and their sieve scripts within a server wihtout
involving SMTP or something like that.

I think the mail loop detection should be left to the MTAs
where it is done already.

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

First, we don't protect the users, we are protecting the
integrity of the mail. I still believe a mail should be
delivered or bounced, never dropped. Secondly, with _less_
intelligence we could get a safer behaviour.

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

I don't say it should result in a "keep", I say the end result
should be a bounce, since the system is badly set up.

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

I'd argue that the system should never loose mail no matter what
(if that is not what the user explicitely tells it to do).
Since not loosing email is
- The mode the entire global email system should operate in
- What the users expect
I don't see why the cyrus server ever should.

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

Oh, I am sorry to hear that. I obviously have to read up a bit
on what information is really stored in there. Maybe we can
find another solution then.


Note: I am absolutely _not_ trying to annoy anyone. I just want
a solution to this problem.

/ragge






More information about the Info-cyrus mailing list