Open imarko opened 10 months ago
Thanks for opening this! Sorry it took a while to reply.
The current behaviour is a consequence of having to handle more complex cases, such that an alias that goes to more than one destination, which can be a mix of valid/invalid and some may not be knowable in advance (e.g. non-local destinations).
But for those cases where we know all destinations are local and we can authoritatively know if they're valid or not, I agree it would be nice to fail at RCPT TO
time.
I'm going to look a bit more into it, and report back.
I took a quick look. Due to the way the alias resolution works today, rejecting early when an alias only has local destinations and they're not valid is not particularly natural.
That said, I'm going to keep this open for a little longer: I want to evaluate the options more thoroughly, and maybe do one or two proof-of-concept patches with a couple of options, before deciding what to do.
If we have an alias pointing to a non-existent local account Chasquid will accept the email and pass it to the MDA. Coming from Exim I was expecting that we'd notice that the resolved alias is not a valid local account and reject the email with a 550 as we'd when sending directly to such a non-existent address.
A downside of the current behavior is that by accepting the email we now have the responsibility to generate the eventual DSN.
To illustrate, let's say that we have the following in aliases:
where
boguslocal
does not exist as a local account.If I execute an
RCPT To: boguslocal@mydomain.com
I get the 550 as expected. However If IRCPT To: myalias@mydomain.com
the email will be accepted and eventually results in a bounce message when the MDA fails to deliver it.