Hi,
I had a look at rfc2033. It is possible to send an individual returncode
after the DATA stage for each recipient.
So befor I try to patch the lmtpd, i would like to discus, which is
the desired/expected behavior. To make discussion easier lets think about
common usecases.
1. discard:
We use Spamassassin to mark spams. The user has the choise to discard
them or to sort them into a folder depending on the spam score.
So we don't want bounce-messages to faked email addresses if the
message would be discard. So if only the discard action is performd
we should return 250 2.1.5 Ok
2. redirect:
Some Users forward there Messages to other accounts. (They may be
over Quota as the sort some mails into other folders). If the only
action that would be performed on a message is "redirect" I would
forward the message and return 250 2.1.5 Ok
3. redirect+fileinto/keep:
This is a tricky case. If a fileinto/keep and a redirect action would
be performed i see the following options
a. perform redirect, but NOT fileinto/keep and return 250 2.1.5 Ok
This means the Message is not stored localy and if
redirections fails the recipient nor the sender are informed.
b. perform redirect, remember message id and redirection and return
452 4.2.2 Over quota / 552 5.2.2 Over quota (remembering is not
needed in case of perm errors)
We need to implement an other Database for this.
c. perform NO action and return 452 4.2.2 Over quota
or 552 5.2.2 Over quota.
4. discard+fileinto/keep
I don't think this is a common usescase, but it may happen as a mail may
match multiple rules. I would like to handle this case in the same way as
Case 3. but I think in this case we can't return 250 2.1.5 Ok as we don't
keep a copy.
Are there other Usescases/Options we should think of?
I also had a look at the sieve rfc3028, but I'm not sure if it is helpfull.
rfc3028 mentions in section "2.10.6 Errors"
Implementations MAY choose to do a full parse, then evaluate the
script, then do all actions. Implementations might even go so far as
to ensure that execution is atomic (either all actions are executed
or none are executed).
Other implementations may choose to parse and run at the same time.
Such implementations are simpler, but have issues with partial
failure (some actions happen, others don't).
...
This specification allows any of these approaches. Solving the
Halting Problem is considered extra credit.
When an error happens, implementations MUST notify the user that an
error occurred, which actions (if any) were taken, and do an implicit
keep.
Is "Over Quota" a runtime error? And if how can we notify the user or
sender without using more space?
--------------------------------------------------------------------------------
M.Menge Tel.: (49) 7071/29-70316
Universitaet Tuebingen Fax.: (49) 7071/29-5912
Zentrum fuer Datenverarbeitung mail:
michael.menge@xxxxxxxxxxxxxxxxxxxx
Waechterstrasse 76
72074 Tuebingen
Attachment:
smime.p7s
Description: S/MIME krytographische Unterschrift
---- Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
