Danger of open-relaying in current config.xml?

[David Legg <da...@searchevent.co.uk>]

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: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org

Re: Danger of open-relaying in current config.xml?

[David Legg <da...@searchevent.co.uk>]

Hi Vincenzo,

Vincenzo Gianferrari Pini wrote:
> 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">) and/or (ii) by enabling the <mailet match="RemoteAddrNotInNetwork=nnn.nnn.nnn.nnn" class="ToProcessor">
> 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.
>   

I see now where my thought processes came unstuck.

I was looking too closely at the use of 'SMTPAuthSuccessful' matchers 
and came away with the impression that the spoolmanager section 
controlled who could send email.  In a way I'm glad to see that, no 
matter how much I muck up the spoolmanager config, I'm unlikely to 
create an open relay ;-)


Thanks for your help
David Legg


---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org

Re: Danger of open-relaying in current config.xml?

[Vincenzo Gianferrari Pini <vi...@praxis.it>]

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: server-user-unsubscribe@james.apache.org
> For additional commands, e-mail: server-user-help@james.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org