You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Thomas Johnson <th...@gmail.com> on 2013/10/30 19:38:31 UTC

Whitelisting based on IP address of last external relay

We have some users who would like to whitelist email based on the IP
address of the last external relay.  This is primarily for times like when
messages are being sent from some webform they trust, or from internal
systems.

My first thought was to simply add that IP to "trusted_networks" in their
per-user configuration, thinking that "ALL_TRUSTED" would hit, and the
shortcircuit rule would fire and just let it in.

But of course, some of the messages pass through other relays first, so
ALL_TRUSTED isn't firing.  One message that hit had these meta headers
added (identifiable info changed, of course).

> X-Spam-Relays-Trusted: [ ip=1.2.3.4 rdns= helo=server.domain.com by=
mail.us.com ident= envfrom= intl=0 id=3d8csD48f2UkYp auth= msa=0 ]
> X-Spam-Relays-Untrusted: [ ip=10.0.20.81 rdns= helo=int-WWW01 by=
server.domain.com ident= envfrom= intl=0 id= auth= msa=0 ]
> X-Spam-Relays-Internal:
> X-Spam-Relays-External: [ ip=1.2.3.4 rdns= helo=server.domain.com by=
mail.us.com ident= envfrom= intl=0 id=3d8csD48f2UkYp auth= msa=0 ] [
ip=10.0.20.81 rdns= helo=int-WWW01 by=server.domain.com ident= envfrom=
intl=0 id= auth= msa=0 ]


In this case, I suppose we could add all reserved address blocks to
trusted_networks globally..but that doesn't seem like such a great idea.
 And it won't help when there's some intermediate relay with a public IP
address...

The other option would be to require that the user list all the other
relays in there, but we would really prefer something more simple:  allow
them to whitelist if the last external relay is in the trusted list.


So...is there a rule or an idea on how to determine if the last external
relay is also trusted?

Or are we going to need to write a plugin?

And if anyone thinks that there's a real problem with this whole thing,
please let me know.  Am I missing something obvious that's going to cause
problems if we whitelist based on the IP address of the last external relay?

Thanks-

Re: Whitelisting based on IP address of last external relay

Posted by Karsten Bräckelmann <gu...@rudersport.de>.
On Wed, 2013-10-30 at 11:38 -0700, Thomas Johnson wrote:
> We have some users who would like to whitelist email based on the IP
> address of the last external relay.  This is primarily for times like
> when messages are being sent from some webform they trust, or from
> internal systems.  

> > X-Spam-Relays-External: [ ip=1.2.3.4 rdns= helo=server.domain.com
> by=mail.us.com ident= envfrom= intl=0 id=3d8csD48f2UkYp auth= msa=0 ]
> [ ip=10.0.20.81 rdns= helo=int-WWW01 by=server.domain.com ident=
> envfrom= intl=0 id= auth= msa=0 ]

> So...is there a rule or an idea on how to determine if the last
> external relay is also trusted?

  RULE_NAME  X-Spam-Relays-External =~ /^[^\]]+ ip=1\.2\.3\.4 /

To ensure matching against the very last external relay, no closing
square bracket may appear before the match.

The Received header this data is parsed from is generated by your MX as
can be seen in the first [...] block, so you also can use the rdns
value. Whether to use -Untrusted or -External depends on your trusted
and internal networks settings -- it appears you have that IP in
trusted, but not in internal.

(The rule is basically identical to a black variant I posted the other
day. The difference is the score.)


> And if anyone thinks that there's a real problem with this whole
> thing, please let me know.  Am I missing something obvious that's
> going to cause problems if we whitelist based on the IP address of the
> last external relay?

No problem, your MX can be trusted with that data.


-- 
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}


Re: Whitelisting based on IP address of last external relay

Posted by Matthias Leisi <ma...@leisi.net>.
On Thu, Oct 31, 2013 at 9:59 AM, Henrik K <he...@hege.li> wrote:

I shortcircuit ALL_TRUSTED with a huge trusted_networks list. :-) So yes
> it's a whitelist for me.  I add networks known to be spam free and operated
> by "friends" (other govenment entities, consulting firms etc).  Everything
> works fine, I've also added all private networks as said so it works for
> their internal hops.
>

At dnswl.org we export our data in trusted_networks format for the data
subscribers, but I fear that uptake of this format has been very, very low.

This would make forwarding or relaying spam through legitimate
intermediaries considerably less painful for recipients.

-- Matthias

Re: Whitelisting based on IP address of last external relay

Posted by Henrik K <he...@hege.li>.
On Thu, Oct 31, 2013 at 11:45:45AM +0100, Matus UHLAR - fantomas wrote:
> >On Wed, Oct 30, 2013 at 11:52:50AM -0700, John Hardin wrote:
> >>"Trust" here is not about "won't spam", and ALL_TRUSTED is not a
> >>whitelist.
> 
> On 31.10.13 10:59, Henrik K wrote:
> >Pfft semantics.
> >
> >I shortcircuit ALL_TRUSTED with a huge trusted_networks list. :-) So yes
> >it's a whitelist for me.  I add networks known to be spam free and operated
> >by "friends" (other govenment entities, consulting firms etc).  Everything
> >works fine, I've also added all private networks as said so it works for
> >their internal hops.
> 
> well, if you re using tusted networks as no spam indicator, it's your
> problem. However the trust path was never meant that way, and it's not good
> idea recommend it to others, since they may have to deal with issues
> resulting of the invalid usade...

What issues?

Most people don't understand the external/trusted concept, and the
documentation on all this is vague anyway.  OP seemed more than savvy to
decide for himself.  Then there are people that don't get it no matter what.

SA is a framework and you can use it anyway it works best for you.


Re: Whitelisting based on IP address of last external relay

Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
>On Wed, Oct 30, 2013 at 11:52:50AM -0700, John Hardin wrote:
>> "Trust" here is not about "won't spam", and ALL_TRUSTED is not a
>> whitelist.

On 31.10.13 10:59, Henrik K wrote:
>Pfft semantics.
>
>I shortcircuit ALL_TRUSTED with a huge trusted_networks list. :-) So yes
>it's a whitelist for me.  I add networks known to be spam free and operated
>by "friends" (other govenment entities, consulting firms etc).  Everything
>works fine, I've also added all private networks as said so it works for
>their internal hops.

well, if you re using tusted networks as no spam indicator, it's your
problem. However the trust path was never meant that way, and it's not good
idea recommend it to others, since they may have to deal with issues
resulting of the invalid usade...
-- 
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Fucking windows! Bring Bill Gates! (Southpark the movie)

Re: Whitelisting based on IP address of last external relay

Posted by Henrik K <he...@hege.li>.
On Wed, Oct 30, 2013 at 11:52:50AM -0700, John Hardin wrote:
>
> "Trust" here is not about "won't spam", and ALL_TRUSTED is not a
> whitelist.

Pfft semantics.

I shortcircuit ALL_TRUSTED with a huge trusted_networks list. :-) So yes
it's a whitelist for me.  I add networks known to be spam free and operated
by "friends" (other govenment entities, consulting firms etc).  Everything
works fine, I've also added all private networks as said so it works for
their internal hops.


Re: Whitelisting based on IP address of last external relay

Posted by Henrik K <he...@hege.li>.
On Wed, Oct 30, 2013 at 11:52:50AM -0700, John Hardin wrote:
>
> "Trust" here is not about "won't spam"

Btw trusted_networks entities haven't been checked in DNS blacklists since
2008...  so in a sense it actually is an whitelist..  ;-)

https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5856#c12


Re: Whitelisting based on IP address of last external relay

Posted by John Hardin <jh...@impsec.org>.
On Wed, 30 Oct 2013, Thomas Johnson wrote:

> We have some users who would like to whitelist email based on the IP
> address of the last external relay.  This is primarily for times like when
> messages are being sent from some webform they trust, or from internal
> systems.
>
> My first thought was to simply add that IP to "trusted_networks" in their
> per-user configuration, thinking that "ALL_TRUSTED" would hit, and the
> shortcircuit rule would fire and just let it in.

"Trust" here is not about "won't spam", and ALL_TRUSTED is not a 
whitelist.

>> X-Spam-Relays-External: [ ip=1.2.3.4 rdns= helo=server.domain.com by=
> mail.us.com ident= envfrom= intl=0 id=3d8csD48f2UkYp auth= msa=0 ] [
> ip=10.0.20.81 rdns= helo=int-WWW01 by=server.domain.com ident= envfrom=
> intl=0 id= auth= msa=0 ]
>
> but we would really prefer something more simple:  allow them to 
> whitelist if the last external relay is in the trusted list.

If you take "trusted list" to mean "sites I trust to not spam", you'd have 
to write a header rule to check the last IP/rDNS in X-Spam-Relays-External 
to see if it's in the list of hosts you trust (which is *not* the SA 
trusted_networks list, you have to explicitly supply that list in the 
rule itself) and apply negative points.

Also take a look at whitelist_from_rcvd, perhaps:

    whitelist_from_rcvd    *@*    trusted_webform.example.com

-- 
  John Hardin KA7OHZ                    http://www.impsec.org/~jhardin/
  jhardin@impsec.org    FALaholic #11174     pgpk -a jhardin@impsec.org
  key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
   ...the Fates notice those who buy chainsaws...
                                               -- www.darwinawards.com
-----------------------------------------------------------------------
  Tomorrow: Halloween