**exact** info about "skip_rbl_checks" needed

["Rob McEwen (PowerView Systems)" <ro...@powerviewsystems.com>]

BACKGROUND:

First, I do NOT use SA for IP or URI based lookups as I do those in my own custom programmed spam filter.

But I do desire to use SA for such things as Razor, SARE rules, ImageInfo, etc.

Therefore, I have the following set up to prevent IP lookups:

skip_rbl_checks 1

And other items are "commented out" to prevent such things as SURBL and URIBL lookups since I'm already doing those, too. Also, I also choose have bayes turned off.

THAT IS THE BACKGROUND... HERE IS THE QUESTION:

1st question:

Some of my incoming mesasges involve messages forwarded to my server via a rule from accounts that some of my clients have on other ISPs mail servers. For such incoming messages, I have been creating a temporary copy of the message where all headers that were ADDED by either the other ISP and/or my server are removed so that the message is brought back to the state that it was in when originally sent by the original sender (just prior to the ISP's mail server received it). This way, SA can work with that the potential spammer actually sent, without any received headers added.

But is that really necessary? Or would I get the same results if, under my configuration described above, I just left the extra added headers in there?

(I'm concerned that, even with skip_rbl_checks turned off, there might still be SPF checking or other things going on???? which then might get messed up if I don't present the message in its "original" form. PLEASE... let me know if that is the case. This will only be about the 10th time that I've asked what other "network checks" happen besides Razor/DCC when skip_rbl_checks is set to true.)

2nd question:

Does SA have any problems working with a file that OTHER programs are currently accessing (in "read" mode)?

Thanks!

Rob McEwen
PowerView Systems
rob@PowerViewSystems.com

Re: **exact** info about "skip_rbl_checks" needed

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

David B Funk wrote:
> On Fri, 26 Jan 2007, Daryl C. W. O'Shea wrote:
> 
>>> Some of my incoming mesasges involve messages forwarded to my server via a rule from accounts that some of my clients have on other ISPs mail servers. For such incoming messages, I have been creating a temporary copy of the message where all headers that were ADDED by either the other ISP and/or my server are removed so that the message is brought back to the state that it was in when originally sent by the original sender (just prior to the ISP's mail server received it). This way, SA can work with that the potential spammer actually sent, without any received headers added.
>>>
>>> But is that really necessary? Or would I get the same results if, under my configuration described above, I just left the extra added headers in there?
>> To get the same functionality without stripping headers you'd have to
>> add the forwarders' IPs to your trusted and internal networks config.
> 
> Pardon my confusion, but wouldn't it be sufficient to just add them to
> the trusted networks list? (IE not adding them to internal too).

If you haven't already defined internal_networks, yes, since 
internal_networks will default to whatever you use for trusted_networks.

Having them in both trusted and internal networks is more similar to 
stripping the received headers than having them in trusted but not internal.


> IIUR, internal networks are for clients that will source messages,
> trusted is for MTAs that feed you. Am I missing something?

I think you are.

  - for something to be internal it has to be trusted
    (you can't have an internal but not trusted relay)

  - relays that act as MXes need to be both trusted and internal

  - all relays between an MX and SA need to also be both trusted and
    internal


Adding the forwarding situation described:

  - the MX for the account forwarding to the local account is acting
    as an MX for the final destination account (forwarding is messy)

  - all relays between an MX (the one for the account forwarding to
    the local account) and SA (thus all relays between the remote MX
    and your MX) need to be both trusted and internal



On the submission side (not involved in the original question) it goes 
something like this:

  - if the MSA isn't an MX or internal relay between an MX and SA
    you want it to be trusted but not internal; otherwise it has to
    be both trusted and internal and you'd better have auth tokens
    in the received headers (or be using the POPAuth plugin)


Daryl

Re: **exact** info about "skip_rbl_checks" needed

[David B Funk <db...@engineering.uiowa.edu>]

On Fri, 26 Jan 2007, Daryl C. W. O'Shea wrote:

> >
> > Some of my incoming mesasges involve messages forwarded to my server via a rule from accounts that some of my clients have on other ISPs mail servers. For such incoming messages, I have been creating a temporary copy of the message where all headers that were ADDED by either the other ISP and/or my server are removed so that the message is brought back to the state that it was in when originally sent by the original sender (just prior to the ISP's mail server received it). This way, SA can work with that the potential spammer actually sent, without any received headers added.
> >
> > But is that really necessary? Or would I get the same results if, under my configuration described above, I just left the extra added headers in there?
>
> To get the same functionality without stripping headers you'd have to
> add the forwarders' IPs to your trusted and internal networks config.

Pardon my confusion, but wouldn't it be sufficient to just add them to
the trusted networks list? (IE not adding them to internal too).

IIUR, internal networks are for clients that will source messages,
trusted is for MTAs that feed you. Am I missing something?


-- 
Dave Funk                                  University of Iowa
<dbfunk (at) engineering.uiowa.edu>        College of Engineering
319/335-5751   FAX: 319/384-0549           1256 Seamans Center
Sys_admin/Postmaster/cell_admin            Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{

Re: **exact** info about "skip_rbl_checks" needed

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

My question... why **exactly** can't webmail line wrap messages?  :)


Rob McEwen (PowerView Systems) wrote:

> 1st question:
> 
> Some of my incoming mesasges involve messages forwarded to my server via a rule from accounts that some of my clients have on other ISPs mail servers. For such incoming messages, I have been creating a temporary copy of the message where all headers that were ADDED by either the other ISP and/or my server are removed so that the message is brought back to the state that it was in when originally sent by the original sender (just prior to the ISP's mail server received it). This way, SA can work with that the potential spammer actually sent, without any received headers added.
> 
> But is that really necessary? Or would I get the same results if, under my configuration described above, I just left the extra added headers in there?

To get the same functionality without stripping headers you'd have to 
add the forwarders' IPs to your trusted and internal networks config.


> (I'm concerned that, even with skip_rbl_checks turned off, there might still be SPF checking or other things going on???? which then might get messed up if I don't present the message in its "original" form. PLEASE... let me know if that is the case. This will only be about the 10th time that I've asked what other "network checks" happen besides Razor/DCC when skip_rbl_checks is set to true.)

SPF checks aren't RBL checks, so skip_rbl_checks doesn't affect them. 
Enabling or disabling the SPF plugin and/or rules affects whether SPF 
checks are done.

As for what other network checks are done; run a message through in 
debug mode and find out.  Everything is logged in the debug output. 
This'll only be about the 2nd time I've suggested this, 8 more to go to 
catch up. :)


> 2nd question:
> 
> Does SA have any problems working with a file that OTHER programs are currently accessing (in "read" mode)?

Just like any other simultaneous file access, if the lock states are 
compatible you're OK.  If there is some file in a lock state that isn't 
compatible with what SA wants to do SA will continue on after a short 
time, so there's no risk in SA hanging up.


Daryl