-
Notifications
You must be signed in to change notification settings - Fork 48
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
Always accept postmaster email for virtual domains #228
Comments
Is there a problem keeping a postmaster account? You can even forward A fallback to the localhost is not so good either because some people On 2016-09-15 15:55, Rimas Kudelis wrote:
|
The problem is that the postmaster account can be deleted and not re-created. |
I understand the initial issue and we need to do something about it. I On 2016-09-15 17:25, Rimas Kudelis wrote:
|
Of course, wanting to re-create the account as an alias is a valid reason. That's why I don't want to just block deleting it. :-) |
Why is it a valid reason. What can the redirect do what a real account On 2016-09-15 18:10, Rimas Kudelis wrote:
|
OK, I misunderstood your comments. I didn't think about this. Indeed, even a conventional account can act as a forward. Should we block deleting postmasters then? |
Yes, it's probably the easiest. How do we handle migrated setups that already deleted the postmaster account? Just create it, or enforce it in some way? |
This is almost the same question as what I asked initially. :) |
I would do a postmaster-check after the login of a domain-admin. It checks if there is either
If there isn't, it either
I tend to use the second option because it doesn't disturb the admin so much (if you only want to reset a password for a user, you don't want to deal with such stuff). However, we risk that the new postmaster-account will not be noticed. |
We could also create postmaster as an alias to this current admin account. But I'm not sure if any of that is the best approach, because you never know when the admin is about to log in, and this doesn't ensure that postmaster will be available when necessary. Maybe a yet another option would be to create a new router which would deliver postmaster e-mails to all admins of the affected domain? It will only be reached when explicit postmaster account doesn't exist, so seems like quite an elegant solution to me. This way we would also not have to block deletion and creation of postmaster account in the UI. Of course it's possible for a domain to have no admins at all, but highly unlikely. |
That would be we just put a router in the end of the router list in exim, which selects all admin from the specific domain? Perhaps better than force a creation or doing such stuff. However, for new setups I would prefer the postmaster to be undeletable. So people see that there is something special about this address and that they can't remove it, was done on purpose. If you delete the postmaster-address and you still receive mails, could take some time to figure out what's happening and why. |
We could say that postmaster emails will now be forwarded to all admin accounts upon postmaster deletion. |
i think blocking deletion of the postmaster account is a good idea, If somebody doesn't like to have a postmaster account, he/she should think about running a mail server at all... |
I have prepared a fix for this issue: #248 |
I think postmaster deletion should be allowed after all. The RFC requires that the email to postmaster must be accepted, it doesn't say anything about the specific implementation. Thus, I think the fallback router is a safeguard good enough. If neither a specific postmaster account, nor a catchall address exists, we could also inform logged in admins that all email to postmaster is being automatically forwarded to all domain admins. Now, about that patch: does the new router actually end up being used? If so, is it being used only for postmaster account? |
It would be much easier on the web-interface because we don't need to check for the existence of such an account (mailbox or forward or catchall). And to handle all cases could be complicated.
Oh, I didn't check the username to be |
I wonder what currently happens if we accept an e-mail to postmaster for a virtual domain which doesn't have a postmaster mailbox/forward. When I fix #218, we'll probably start rejecting such e-mails instead. Since RFC's require us to have such address, I'm thinking what options we have.
The text was updated successfully, but these errors were encountered: