PBL using -notfirsthop vs -lastexternal (Re: spamhaus' PBL is now *active* (in beta ... but still active). now what? )

[Justin Mason <jm...@jmason.org>]

Daryl C. W. O'Shea writes:
> If you're 
> referring to jm's post, I think he just made those rules up as they're 
> not what we're publishing for 3.1.

It's the rules from SVN trunk.

> -lastexternal is exactly what they're asking for.  In the case where the 
> client connects directly to their MSA which then connects directly to 
> your MX, -lastexternal is functionally equivalent to -notfirsthop.
> 
> -lastexternal is almost definitely what you want to use for any dynamic 
> client sort of list as it allows for people running their own MSA that 
> has a dynamic-listed IP which then forwards to a smarthost which in turn 
> connects to your MX.  -notfirsthop would FP for this setup.

hmm. I'd better fix trunk then ;)

--j.

Re: PBL using -notfirsthop vs -lastexternal (Re: spamhaus' PBL is now *active* (in beta ... but still active). now what? )

["Daryl C. W. O'Shea" <sp...@dostech.ca>]

John Rudd wrote:

> Is there an SA function that will just return an array of Relays that 
> fit a given one of these criteria?  Such as:
> 
> @relays = get_relays(options);

There are no accessors for it, you've got to access the arrays directly. :(


> where options is a comma delimited string of words like:
>    Trusted      - include a given relay if it is trusted

@{$pms->{relays_trusted}};


>    Untrusted    - include a relay if it is untrusted

@{$pms->{relays_untrusted}};


>    External     - include a relay if it is external

@{$pms->{relays_external}};


>    Internal     - include a relay if it is internal

@{$pms->{relays_internal}};


>    LastExternal - do NOT include the relay if it is NOT the
>                   most recent external relay

$pms->{relays_external}->[0];


>    NotFirstHop  - do NOT include the relay if there are multiple
>                   relays and this one was the least recent relay

See the "check_rbl_backend" sub in the DNSEval plugin.

Using the correct elements from $pms->{relays_external} will also get 
you what you want.  Use them all if there's only one, otherwise use all 
but the last one.


> and the returned relay array meets the specified criteria, and contains 
> the same data about the relays that are in the pseudo-headers?

The pseudo headers are generated from the above arrays.


> An SA function, particularly a PerMsgStatus method, that did something 
> like this would be VERY useful.

While accessors would be ideal, at least in an academic sense, you can 
depend on the above arrays being there.

> 
> So, if I'm writing a plugin, and I want to get the last external relay, 
> I can just do:
> 
> $relay = shift($pms->get_relays("LastExternal"));
> 
> or if I wanted to say "don't do this stuff if there were trusted relays":

$pms->{num_relays_trusted};


> unless ($pms->get_relays("Trusted")) {
>    #do stuff
>    }
> 


 From the PMS "extract_message_metadata" sub:

    	relays_trusted relays_trusted_str num_relays_trusted
         relays_untrusted relays_untrusted_str num_relays_untrusted
         relays_internal relays_internal_str num_relays_internal
         relays_external relays_external_str num_relays_extern
	num_relays_unparseable


Daryl

Re: PBL using -notfirsthop vs -lastexternal (Re: spamhaus' PBL is now *active* (in beta ... but still active). now what? )

[John Rudd <jr...@ucsc.edu>]

Daryl C. W. O'Shea wrote:

> 
> Yeah, -notfirsthop is good for lists that list known zombies, open 
> relays, and crap like that.  Generic dynamic lists are better off as 
> -lastexternal to avoid FPs (I know of lots of businesses that are forced 
> to smarthost their mail through Bell's MSAs due to SORBS listings of 
> static connections because of Bell's crappy rDNS naming scheme).
> 


Is there an SA function that will just return an array of Relays that 
fit a given one of these criteria?  Such as:

@relays = get_relays(options);


where options is a comma delimited string of words like:
    Trusted      - include a given relay if it is trusted
    Untrusted    - include a relay if it is untrusted
    External     - include a relay if it is external
    Internal     - include a relay if it is internal
    LastExternal - do NOT include the relay if it is NOT the
                   most recent external relay
    NotFirstHop  - do NOT include the relay if there are multiple
                   relays and this one was the least recent relay

and the returned relay array meets the specified criteria, and contains 
the same data about the relays that are in the pseudo-headers?

An SA function, particularly a PerMsgStatus method, that did something 
like this would be VERY useful.


So, if I'm writing a plugin, and I want to get the last external relay, 
I can just do:

$relay = shift($pms->get_relays("LastExternal"));

or if I wanted to say "don't do this stuff if there were trusted relays":

unless ($pms->get_relays("Trusted")) {
    #do stuff
    }

Re: PBL using -notfirsthop vs -lastexternal (Re: spamhaus' PBL is now *active* (in beta ... but still active). now what? )

["Daryl C. W. O'Shea" <sp...@dostech.ca>]

Justin Mason wrote:
> Daryl C. W. O'Shea writes:
>> If you're 
>> referring to jm's post, I think he just made those rules up as they're 
>> not what we're publishing for 3.1.
> 
> It's the rules from SVN trunk.

Ah.


>> -lastexternal is exactly what they're asking for.  In the case where the 
>> client connects directly to their MSA which then connects directly to 
>> your MX, -lastexternal is functionally equivalent to -notfirsthop.
>>
>> -lastexternal is almost definitely what you want to use for any dynamic 
>> client sort of list as it allows for people running their own MSA that 
>> has a dynamic-listed IP which then forwards to a smarthost which in turn 
>> connects to your MX.  -notfirsthop would FP for this setup.
> 
> hmm. I'd better fix trunk then ;)

Yeah, -notfirsthop is good for lists that list known zombies, open 
relays, and crap like that.  Generic dynamic lists are better off as 
-lastexternal to avoid FPs (I know of lots of businesses that are forced 
to smarthost their mail through Bell's MSAs due to SORBS listings of 
static connections because of Bell's crappy rDNS naming scheme).


Daryl