You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I would like to build an equivalent of virtual alias files using sieve scripts and thus need to potentially redirect a mail to its sender. Imagine e.g. getting a request to [email protected] which redirects to a bunch of private mails. If I now answer from one of these private mails, I usually put [email protected] in CC and receive a copy of my mail.
Implementations MUST take measures to implement loop control,
possibly including adding headers to the message or counting Received
headers as specified in section 6.2 of [SMTP]. If an implementation
detects a loop, it causes an error.
And Section 6.2 says
Simple counting of the number of "Received:" headers in a message has
proven to be an effective, although rarely optimal, method of
detecting loops in mail systems. SMTP servers using this technique
SHOULD use a large rejection threshold, normally at least 100
Received entries. Whatever mechanisms are used, servers MUST contain
provisions for detecting and stopping trivial loops.
Even with the last sentence, I think that the current approach is overly restrictive and counting Received headers would be a good approach.
Alternatively, this behavior could be limited to trusted scripts or behind a flag.
The text was updated successfully, but these errors were encountered:
Hi,
I would like to build an equivalent of virtual alias files using sieve scripts and thus need to potentially redirect a mail to its sender. Imagine e.g. getting a request to [email protected] which redirects to a bunch of private mails. If I now answer from one of these private mails, I usually put [email protected] in CC and receive a copy of my mail.
This is prevented by
sieve/src/runtime/actions/action_redirect.rs
Line 44 in 0e24d13
Relevant portions of the Sieve RFC 5228:
And Section 6.2 says
Even with the last sentence, I think that the current approach is overly restrictive and counting
Received
headers would be a good approach.Alternatively, this behavior could be limited to trusted scripts or behind a flag.
The text was updated successfully, but these errors were encountered: