mjl- / mox

modern full-featured open source secure mail server for low-maintenance self-hosted email
https://www.xmox.nl
MIT License
3.71k stars 113 forks source link

errors referencing existing addresses from v0.0.1 when adding new account on v0.0.4 #40

Closed sherief closed 7 months ago

sherief commented 1 year ago

I migrated from 0.0.1 to 0.0.4 and the first time I tried to add a new account I got multiple instances of this error, each for one of the existing mail accounts I had set up. The instance below is for my primary address, sherief at sherief dot fyi:

error: "deprecated: destination with localpart-only key will be removed in the future, replace it with a full email address, by appending the default domain" (pkg: mox; localpart: sherief; address: sherief@sherief.fyi; account: sherief)

I'm not sure what this means, or what's actionable on my part here. Any guidance?

mjl- commented 1 year ago

ah yes, that message is a bit obscure. and although it is logged as an error, it is more a warning. you can solve it by changing config/domains.conf. you probably have something like this at the moment:

Accounts:                       
        sherief:                    
                Domain: sherief.fyi
                Destinations:   
                        sherief:
                                ...

And mox wants you to use this:

Accounts:                       
        sherief:                    
                Domain: sherief.fyi
                Destinations:   
                        sherief@sherief.fyi
                                ...

i.e. the "key" in the "Destinations" map should be a full email address, not just the localpart (that is combined with the value of "Domain").

perhaps i'll make a change to automatically rewrite domains.conf (all information is present). or otherwise try to make the message more actionable.

mjl- commented 7 months ago

closing this issue, it was probably addresses sufficiently with latest commit. later commit 1abadc549952ee7e0b3f6be230b6e15eb6ef0d4b introduced the "warn" log level which this warning now uses, so should be more clear now. thanks for reporting!