Hi Matt - We need you to put all your wonderful replies and commentary up on the James website as part of the documentation. Some of the stuff there is pretty sparse and you are doing a great job of explaining things! ;-) I will intersperse a few comments below -
On 02/20/2019 09:50 AM, cryptearth wrote: > 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.*" Understood. This is a perfectly valid approach to cutting down on spam being sent through a James server.. It would be interesting to know if this is the most commonly used approach, or whether most servers are using SMTP authentication instead, or whether most servers are using both methods. My argument is not against using this particular matcher/mailet, but that the default configuration files should come supplied and set up in a way that reflects the most common usage. To restrict emails to only come from users on the local host, by default in the supplied config file, seems to be awfully restrictive and uncommon usage, but I am only guessing. My suspicion is that most folks using James are going to use SMTP authentication, at least that is my own personal experience, and for users to be on a LAN/WLAN. So I am wondering if this matcher/mailet should not be enabled by default and SMTP authentication should be enabled instead, by default. I understand the need for James to start up safely, from the default configurations, so as not to be an open relay by default. > > If you are using SMTP authentication then you can (and generally > should) disable this matcher/mailet pair." I think this relationship between using SMTP authentication and this matcher/mailet should be automated. In other words, if SMTP authentication is turned on then this matcher/mailet should be disabled by default automatically. And vice/versa. I also think that the administrator should be able to override this automated relationship, with an explicitly set option, if for some reason both or neither approaches are wanted. Again, the real question is, what is the most common way James is being configured, and how can mistakes, such as I made, be minimized. The goal being to keep James robust and easy to manage. > > 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 took the "Don't touch it" approach as much as I could. Trouble is I didn't catch this somewhat hidden matcher/mailet nor did I expect that the James server would come up with a very restrictive policy that was preventing me from testing/using it from somewhere else on my LAN. Especially after I had enabled SMTP authentication, which kinda implied, at least to me, that I would be able to use James from across my LAN. This is re-enforce by the observation the IMAP and POP3 were working from across my LAN and made it difficult to understand why SMTP wouldn't. > > 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? Yep! :-) And don't get me wrong, I am NOT complaining about Apache James really, just throwing out some thoughts to think about, which might make it easier for others following in my footsteps, in installing and bringing up James. I am very impressed with the amount of work that has obviously gone into developing James, and totally appreciate the amount of support you and Benoit have given me! I am going to work on getting SSL/TLS working with LetsEncrypt certificates next... Marc.. > > 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 > -- Linux Counter
