Evening all, Matt here.
Marc, let's look at the doc:
"This is an anti-relay matcher/mailet combination
Emails sent from servers not in the network list are rejected as spam.
This is one method of preventing your server from being used as an open
relay. Make sure you understand how to prevent your server from
becoming an open relay before changing this configuration. See
also<authorizedAddresses>in SMTP Server
This matcher/mailet combination must come after local delivery has been
performed. Otherwise local users will not be able to receive email from
senders not in this remote address list.
If you are using this matcher/mailet you will probably want to update
the configuration to include your own network/addresses. The matcher
can be configured with a comma separated list of IP addresses wildcarded
IP subnets, and wildcarded hostname subnets.
e.g. "RemoteAddrNotInNetwork=127.0.0.1, abc.de.*, 192.168.0.*"
If you are using SMTP authentication then you can (and generally should)
disable this matcher/mailet pair."
So, as far as I understand it: "Don't touch it if you don't understand
it - but you should remove it anyway when smtp auth is used.". Guess
that's it for you.
I've never encountered that as I only have my domain cryptearth.de in
domainlist - neither localhost nor other local entries. I've never tried
to send a mail to localhost - allthough, that's one part of my own
current thread about overwrite local service mails from
sendmail-nullclient used by apache and cron - but that's its own topic.
So still have this matcher/mailet in my config, allthough I have smtp
auth enabled.
So, as far as I understood your reply, you now finally got james up and
running so you can also send mails to others?
Matt
Am 20.02.2019 um 16:59 schrieb Marc Chamberlin:
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
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org
For additional commands, e-mail: server-user-h...@james.apache.org
