Morning Benoit ;-) This could get into being a philosophical discussion for certain! I have mixed feelings about customization of error messages, and you are correct in saying I could change this particular one. I have always approached software design with the attitude that error handling and error messages should be carefully crafted so as to guide users to a solution, not just tell them that something went wrong. Which is what this particular error message is doing when left in it's current default state. We could change/customize it for our own users, (actually I will just remove this mailet) but doing so leads to a different issue. If everyone who installs James servers (or any other application for that matter) is allowed to customize error messages then it leads to a non-standard environment. Often, when users encounter an error message, that doesn't provide an understandable solution, they will then Google it looking for a solution, hoping to find a guru or a collective mind to provide one. Even in cases such as this, where the solution will require the assistance of the James administrators to solve this problem, the user needs to be told that he/she must contact them AND what exactly they need to tell the administrators. I would craft this message to say, "Your email server is rejecting your request to send your email messages. Please contact your Internet Service Provider and/or IT administrator and tell them that your email server is rejecting your request to relay email because it is not configured to accept email from your IP address. They need to check the configuration of the anti-relay matcher/mailet or remove this matcher/mailet from the server." In this way, both the user and the administrators have been guided to a solution making it easier to resolve this problem. I am not sure that I would design this matcher/mailet to allow easy customization of the error message however, I think that should be only done internally within the code itself. But you could convince me otherwise if you can provide me with some compelling reasons to allow customization.
Marc.... On 02/20/2019 12:15 AM, Benoit Tellier wrote: > Hi. > > This is very true. But the technical knowledge limitation is not the > only one... There is also internationalization + text/plain messages... > > Note that "Bounce" mailet family allows a '<message>' field allowing you > to maybe further explain this to non techie users you might have to > handle - and in the language of your choice, which is a big +. > > Cheers, > > Benoit > > On 2/20/19 12:02 PM, Marc Chamberlin wrote: >> Funny that I wasn't getting the notice "550 - Requested action not >> taken: relaying denied" in a bounce email... (but even that is a really >> bad error message that most users will not understand nor know what to >> do about it.) > --------------------------------------------------------------------- > To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org > For additional commands, e-mail: server-user-h...@james.apache.org > -- Linux Counter
