Hi David, there are two issues here:
1) Enabling or disabling the whitelist mailet has no effect on relaying, only on spam processing. Relaying is controlled (i) by the SMTP Authentication option (see <authRequired> in <smtpserver enabled="true">) that blocks open relaying during SMTP connection time, and/or (ii) by enabling the <mailet match="RemoteAddrNotInNetwork=nnn.nnn.nnn.nnn" class="ToProcessor"> in the transport processor, that limits relaying to authorized IP addresses. The IsInWhiteList matcher entry just reduces the risk of loosing false positives after anti-spam bayesian processing or other anti-spam checks. Nothing to do with open relaying. 2) It's true that the lack of a naming convention makes it difficult to know what is the default <passThrough> behaviour of a mailet, so that understanding a config.xml can be difficult.. Now it's too late to change the names of the existing mailets. Perhaps putting and mantaining a comment at the beginning of our standard config.xml file with a very simple list of such behaviour would help. Ciao, Vincenzo David Legg wrote: > Hi, > > I've been examining the config.xml file supplied with the 2.3.1 release! > > It looks to me that there is a small security risk if you enable the > whitelist. I think that remote users who have been placed on a local > user's white list can simply route any message they like through the > server without even having to authenticate. > > This section: - > > <!-- If the sender is in a recipient's whitelist, it is a valid > sender, --> > <mailet match="IsInWhiteList=db://maildb" class="ToProcessor" > onMatchException="noMatch"> > <processor> transport </processor> > </mailet> > > Will simply send ANY message to the transport process whether the user > is authorized or not and whether the message is considered spam or not. > > I'm beginning to realize that reading the config file is very difficult > ;-) The main problem I have is not knowing whether messages will > terminate at a particular mailet or pass on down to the next matcher. > You have to keep a close eye on each Matcher and Mailet's Javadoc entry > as you traverse the config file... and that's hard! I don't know how to > fix that kind of information in the file. Maybe some form of consistent > mailet naming convention? > > Does anyone agree? > > Regards, > David Legg > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
