You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-user@james.apache.org by Bud Bach <bu...@bachcg.com> on 2007/01/24 18:56:56 UTC

Accurately identifying locally originated mail

I have an application that runs on the same machine as my james server that
sends out registration confirmation messages.  I have the smtp server for
james configured to require authentication:

         <authRequired>true</authRequired>

but I set authorizedAddresses to allow messages from the local host to pass:

         <authorizedAddresses>127.0.0.0/8</authorizedAddresses>

In the root processor I have:

         <mailet match="SMTPAuthSuccessful" class="ToProcessor">
            <processor> transport </processor>
         </mailet>

to bypasss various spam checks.

Can I safely add a:

         <mailet match="RemoteAddrInNetwork=127.0.0.0/8"
class="ToProcessor">
            <processor> transport </processor>
         </mailet>

or something similar to allow non-authenticated senders that are on the
local machine to bypass the spam checks as well?  Could the "remote" address
be spoofed thereby allowing my server to unintentionally relay mail if I do
this?  Thanks.  -- Bud


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


Re: Accurately identifying locally originated mail

Posted by Danny Angus <da...@apache.org>.
On 1/24/07, Bud Bach <bu...@bachcg.com> wrote:

> or something similar to allow non-authenticated senders that are on the
> local machine to bypass the spam checks as well?  Could the "remote" address
> be spoofed thereby allowing my server to unintentionally relay mail if I do
> this?  Thanks.  -- Bud

I think it is highly unlikely (without testing it couldn't say for
sure) because the IP address is got from the socket connection and if
it is wrong I imagine the connection wouldn't work, and the AUTH local
bypass would be vulnerable, which would be a big no-no.

I think your plan is a reasonable one.

d.

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