Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow redirect to sender #11

Open
nmxhc opened this issue Jan 9, 2025 · 0 comments
Open

Allow redirect to sender #11

nmxhc opened this issue Jan 9, 2025 · 0 comments

Comments

@nmxhc
Copy link

nmxhc commented Jan 9, 2025

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

// Try to avoid forwarding loops

Relevant portions of the Sieve RFC 5228:

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant