Re: [qmailtoaster] SRS with multi frontend smtp

[Erik Espinoza]

SRS is just a rewriting scheme. It has no pass/fail, just rewrite conditions.

No need to worry about rejectoins

Erik

On 1/27/07, Philip Nix Guru <[EMAIL PROTECTED]> wrote:

Actually
it is more :
incoming : internet -> scanners -> real box
if all scanners are down, internet -> real box (lowest mx priority)
outgoing  : realbox -> internet(on that setup, customers email arent
scanned, we "trust" them in a way :) )

For instance with spf , all 4 servers can check if the sender's domain
complies with the domain's stated policy.
so mail can be dropped/ rejected by the scanners.
I was wondering if srs could somehow drop a bounced message at the
scanners level in that setup.
Just curious .. couldnt find much infos about it

Have a nice evening Erik and thx for the infos ..



Erik Espinoza wrote:
> Hey Phil,
>
> Sounds like you have the following config:
>
> real box -> 3 scanners -> Internet
>
> If this is correct, then only the real box needs srs setup.
>
> As far as the latest srs patch, we're already including it on the
> devel site. Marcelo and I are in communication about srs status.
>
> Erik
>
> On 1/27/07, Philip Nix Guru <[EMAIL PROTECTED]> wrote:
>> Hi
>> yes was thinking doing something similiar
>> My concern is more the return bounced message, the outgoing signing
>> process is trivial
>>
>> The setup I wanna add SRS support is
>> 1 machine running a qtoaster based system, holding the real users,
>> machine used by the same users to send emails..
>> Then there are 3 other qtoaster machines dedicated to only do the
>> scanning and routing of the incoming mails
>> once scanned , emails are smtprouted to that box mentioned previously
>> I was wondering how the srs process handles that situation
>> If you only set srs on the box with the real users and the mx to that
>> same box .. it should work
>> I was wondering if setting it aswell on the filtering machines could
>> change its behavior
>>
>> I didnt find any infos on that sort of setup.
>>
>> On anothe note , a new version of the patch has been released
>> http://opensource.mco2.net/download/qmail/qmail-srs-0.5.patch
>> 2007-01-11 (0.5):
>>
>> * Added parameters srs_separator and srs_alwaysrewrite from libsrs2.
>>
>> just for the info :)
>>
>>
>> Erik Espinoza wrote:
>> > Philip,
>> >
>> > I don't know how you have everything configured, so I can't tell you
>> > how to run your infrastructure.
>> >
>> > As far as multiple entries, I'd recommend doing  srs1.yourdomain.com
>> > for the first box, srs2.yourdomain.com and srs3 and so forth. Unless
>> > they are running in a clustered configuration.
>> >
>> > Thanks,
>> > Erik
>> >
>> > On 1/27/07, Philip Nix Guru <[EMAIL PROTECTED]> wrote:
>> >> Forgot one thing :)
>> >> the srs.yourdoamin MX record should point to the server hosting
>> the real
>> >> users or it can point to the MX with the lower priorities ?
>> >> and can you set as many MX entries as you want ?
>> >> Thx again for the help
>> >> Cheers
>> >> -P
>> >>
>> >>
>> >> Erik Espinoza wrote:
>> >> > Hey Phil,
>> >> >
>> >> > Set SRS on the machine that has real users. If both machines
>> have real
>> >> > users, set SRS up on both.
>> >> >
>> >> > Don't use the same srs_domain/srs_secret unless both machines are
>> >> > running in a clustered config.
>> >> >
>> >> > Erik
>> >> >
>> >> > On 1/27/07, Philip Nix Guru <[EMAIL PROTECTED]> wrote:
>> >> >> Hello
>> >> >> I was just thinking 
>> >> >> If you have lets say a couple of frontend smtp servers filtering
>> >> emails
>> >> >> before delivering (smtproute) to some other qtoaster machines
>> holding
>> >> >> your mailboxes.
>> >> >> How would you implement SRS ? If you send an email with  machine B
>> >> >> (where you have mailboxes and srs configured), you change your
>> >> envelope
>> >> >> sender address of your outgoing message and if then the email gets
>> >> >> bounced but goes through another smtp (frontend),
>> >> >> machine A (the filtering machine) .
>> >> >> How would that work ?
>> >> >>
>> >> >> You should set exactly same SECRET on all machines or by having
>> >> >> smtproute configured for that domain the srs check would get by
>> >> passed ?
>> >> >> or maybe point srs.YOURDOMAIN mx record to the machine used for
>> >> sending
>> >> >> ? (if you got a few ... ?)
>> >> >>
>> >> >> Just wondering on the good setup in that kind of situation
>> >> >>
>> >> >> Thx
>> >> >> -P
>> >> >>
>> >> >>
>> -
>> >> >>  QmailToaster hosted by: VR Hosted 
>> >> >>
>> -
>> >> >> To unsubscribe, e-mail:
>> >> [EMAIL PROTECTED]
>> >> >> For additional commands, e-mail:
>> >> [EMAIL PROTECTED]
>> >> >>
>> >> >>
>> >> >
>> >> >
>> -
>> >> > QmailToaster hosted by: VR Hosted 
>> >> >
>> ---

Re: [qmailtoaster] SRS with multi frontend smtp

[Philip Nix Guru]

Actually
it is more :
incoming : internet -> scanners -> real box
if all scanners are down, internet -> real box (lowest mx priority)
outgoing  : realbox -> internet(on that setup, customers email arent 
scanned, we "trust" them in a way :) )


For instance with spf , all 4 servers can check if the sender's domain 
complies with the domain's stated policy.

so mail can be dropped/ rejected by the scanners.
I was wondering if srs could somehow drop a bounced message at the 
scanners level in that setup.

Just curious .. couldnt find much infos about it

Have a nice evening Erik and thx for the infos ..



Erik Espinoza wrote:

Hey Phil,

Sounds like you have the following config:

real box -> 3 scanners -> Internet

If this is correct, then only the real box needs srs setup.

As far as the latest srs patch, we're already including it on the
devel site. Marcelo and I are in communication about srs status.

Erik

On 1/27/07, Philip Nix Guru <[EMAIL PROTECTED]> wrote:

Hi
yes was thinking doing something similiar
My concern is more the return bounced message, the outgoing signing
process is trivial

The setup I wanna add SRS support is
1 machine running a qtoaster based system, holding the real users,
machine used by the same users to send emails..
Then there are 3 other qtoaster machines dedicated to only do the
scanning and routing of the incoming mails
once scanned , emails are smtprouted to that box mentioned previously
I was wondering how the srs process handles that situation
If you only set srs on the box with the real users and the mx to that
same box .. it should work
I was wondering if setting it aswell on the filtering machines could
change its behavior

I didnt find any infos on that sort of setup.

On anothe note , a new version of the patch has been released
http://opensource.mco2.net/download/qmail/qmail-srs-0.5.patch
2007-01-11 (0.5):

* Added parameters srs_separator and srs_alwaysrewrite from libsrs2.

just for the info :)


Erik Espinoza wrote:
> Philip,
>
> I don't know how you have everything configured, so I can't tell you
> how to run your infrastructure.
>
> As far as multiple entries, I'd recommend doing  srs1.yourdomain.com
> for the first box, srs2.yourdomain.com and srs3 and so forth. Unless
> they are running in a clustered configuration.
>
> Thanks,
> Erik
>
> On 1/27/07, Philip Nix Guru <[EMAIL PROTECTED]> wrote:
>> Forgot one thing :)
>> the srs.yourdoamin MX record should point to the server hosting 
the real

>> users or it can point to the MX with the lower priorities ?
>> and can you set as many MX entries as you want ?
>> Thx again for the help
>> Cheers
>> -P
>>
>>
>> Erik Espinoza wrote:
>> > Hey Phil,
>> >
>> > Set SRS on the machine that has real users. If both machines 
have real

>> > users, set SRS up on both.
>> >
>> > Don't use the same srs_domain/srs_secret unless both machines are
>> > running in a clustered config.
>> >
>> > Erik
>> >
>> > On 1/27/07, Philip Nix Guru <[EMAIL PROTECTED]> wrote:
>> >> Hello
>> >> I was just thinking 
>> >> If you have lets say a couple of frontend smtp servers filtering
>> emails
>> >> before delivering (smtproute) to some other qtoaster machines 
holding

>> >> your mailboxes.
>> >> How would you implement SRS ? If you send an email with  machine B
>> >> (where you have mailboxes and srs configured), you change your
>> envelope
>> >> sender address of your outgoing message and if then the email gets
>> >> bounced but goes through another smtp (frontend),
>> >> machine A (the filtering machine) .
>> >> How would that work ?
>> >>
>> >> You should set exactly same SECRET on all machines or by having
>> >> smtproute configured for that domain the srs check would get by
>> passed ?
>> >> or maybe point srs.YOURDOMAIN mx record to the machine used for
>> sending
>> >> ? (if you got a few ... ?)
>> >>
>> >> Just wondering on the good setup in that kind of situation
>> >>
>> >> Thx
>> >> -P
>> >>
>> >> 
-

>> >>  QmailToaster hosted by: VR Hosted 
>> >> 
-

>> >> To unsubscribe, e-mail:
>> [EMAIL PROTECTED]
>> >> For additional commands, e-mail:
>> [EMAIL PROTECTED]
>> >>
>> >>
>> >
>> > 
-

>> > QmailToaster hosted by: VR Hosted 
>> > 
-
>> > To unsubscribe, e-mail: 
[EMAIL PROTECTED]

>> > For additional commands, e-mail:
>> [EMAIL PROTECTED]
>> >
>>
>>
>> -
>>  QmailToaster hosted by: VR Hosted 
>> -
>> To unsubscribe, e-mail: 
[EMAIL PROTECTED]
>> For additional commands, e-mail: 
[EMAIL PROTECTED]

>>
>>
>
> ---

Re: [qmailtoaster] SRS with multi frontend smtp

[Erik Espinoza]

Hey Phil,

Sounds like you have the following config:

real box -> 3 scanners -> Internet

If this is correct, then only the real box needs srs setup.

As far as the latest srs patch, we're already including it on the
devel site. Marcelo and I are in communication about srs status.

Erik

On 1/27/07, Philip Nix Guru <[EMAIL PROTECTED]> wrote:

Hi
yes was thinking doing something similiar
My concern is more the return bounced message, the outgoing signing
process is trivial

The setup I wanna add SRS support is
1 machine running a qtoaster based system, holding the real users,
machine used by the same users to send emails..
Then there are 3 other qtoaster machines dedicated to only do the
scanning and routing of the incoming mails
once scanned , emails are smtprouted to that box mentioned previously
I was wondering how the srs process handles that situation
If you only set srs on the box with the real users and the mx to that
same box .. it should work
I was wondering if setting it aswell on the filtering machines could
change its behavior

I didnt find any infos on that sort of setup.

On anothe note , a new version of the patch has been released
http://opensource.mco2.net/download/qmail/qmail-srs-0.5.patch
2007-01-11 (0.5):

* Added parameters srs_separator and srs_alwaysrewrite from libsrs2.

just for the info :)


Erik Espinoza wrote:
> Philip,
>
> I don't know how you have everything configured, so I can't tell you
> how to run your infrastructure.
>
> As far as multiple entries, I'd recommend doing  srs1.yourdomain.com
> for the first box, srs2.yourdomain.com and srs3 and so forth. Unless
> they are running in a clustered configuration.
>
> Thanks,
> Erik
>
> On 1/27/07, Philip Nix Guru <[EMAIL PROTECTED]> wrote:
>> Forgot one thing :)
>> the srs.yourdoamin MX record should point to the server hosting the real
>> users or it can point to the MX with the lower priorities ?
>> and can you set as many MX entries as you want ?
>> Thx again for the help
>> Cheers
>> -P
>>
>>
>> Erik Espinoza wrote:
>> > Hey Phil,
>> >
>> > Set SRS on the machine that has real users. If both machines have real
>> > users, set SRS up on both.
>> >
>> > Don't use the same srs_domain/srs_secret unless both machines are
>> > running in a clustered config.
>> >
>> > Erik
>> >
>> > On 1/27/07, Philip Nix Guru <[EMAIL PROTECTED]> wrote:
>> >> Hello
>> >> I was just thinking 
>> >> If you have lets say a couple of frontend smtp servers filtering
>> emails
>> >> before delivering (smtproute) to some other qtoaster machines holding
>> >> your mailboxes.
>> >> How would you implement SRS ? If you send an email with  machine B
>> >> (where you have mailboxes and srs configured), you change your
>> envelope
>> >> sender address of your outgoing message and if then the email gets
>> >> bounced but goes through another smtp (frontend),
>> >> machine A (the filtering machine) .
>> >> How would that work ?
>> >>
>> >> You should set exactly same SECRET on all machines or by having
>> >> smtproute configured for that domain the srs check would get by
>> passed ?
>> >> or maybe point srs.YOURDOMAIN mx record to the machine used for
>> sending
>> >> ? (if you got a few ... ?)
>> >>
>> >> Just wondering on the good setup in that kind of situation
>> >>
>> >> Thx
>> >> -P
>> >>
>> >> -
>> >>  QmailToaster hosted by: VR Hosted 
>> >> -
>> >> To unsubscribe, e-mail:
>> [EMAIL PROTECTED]
>> >> For additional commands, e-mail:
>> [EMAIL PROTECTED]
>> >>
>> >>
>> >
>> > -
>> > QmailToaster hosted by: VR Hosted 
>> > -
>> > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> > For additional commands, e-mail:
>> [EMAIL PROTECTED]
>> >
>>
>>
>> -
>>  QmailToaster hosted by: VR Hosted 
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
> -
> QmailToaster hosted by: VR Hosted 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>


-
 QmailToaster hosted by: VR Hosted 
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
QmailToaster hosted by: VR

Re: [qmailtoaster] SRS with multi frontend smtp

[Philip Nix Guru]

Hi
yes was thinking doing something similiar
My concern is more the return bounced message, the outgoing signing 
process is trivial


The setup I wanna add SRS support is
1 machine running a qtoaster based system, holding the real users, 
machine used by the same users to send emails..
Then there are 3 other qtoaster machines dedicated to only do the 
scanning and routing of the incoming mails

once scanned , emails are smtprouted to that box mentioned previously
I was wondering how the srs process handles that situation
If you only set srs on the box with the real users and the mx to that 
same box .. it should work
I was wondering if setting it aswell on the filtering machines could 
change its behavior


I didnt find any infos on that sort of setup.

On anothe note , a new version of the patch has been released
http://opensource.mco2.net/download/qmail/qmail-srs-0.5.patch
2007-01-11 (0.5):

   * Added parameters srs_separator and srs_alwaysrewrite from libsrs2.

just for the info :)


Erik Espinoza wrote:

Philip,

I don't know how you have everything configured, so I can't tell you
how to run your infrastructure.

As far as multiple entries, I'd recommend doing  srs1.yourdomain.com
for the first box, srs2.yourdomain.com and srs3 and so forth. Unless
they are running in a clustered configuration.

Thanks,
Erik

On 1/27/07, Philip Nix Guru <[EMAIL PROTECTED]> wrote:

Forgot one thing :)
the srs.yourdoamin MX record should point to the server hosting the real
users or it can point to the MX with the lower priorities ?
and can you set as many MX entries as you want ?
Thx again for the help
Cheers
-P


Erik Espinoza wrote:
> Hey Phil,
>
> Set SRS on the machine that has real users. If both machines have real
> users, set SRS up on both.
>
> Don't use the same srs_domain/srs_secret unless both machines are
> running in a clustered config.
>
> Erik
>
> On 1/27/07, Philip Nix Guru <[EMAIL PROTECTED]> wrote:
>> Hello
>> I was just thinking 
>> If you have lets say a couple of frontend smtp servers filtering 
emails

>> before delivering (smtproute) to some other qtoaster machines holding
>> your mailboxes.
>> How would you implement SRS ? If you send an email with  machine B
>> (where you have mailboxes and srs configured), you change your 
envelope

>> sender address of your outgoing message and if then the email gets
>> bounced but goes through another smtp (frontend),
>> machine A (the filtering machine) .
>> How would that work ?
>>
>> You should set exactly same SECRET on all machines or by having
>> smtproute configured for that domain the srs check would get by 
passed ?
>> or maybe point srs.YOURDOMAIN mx record to the machine used for 
sending

>> ? (if you got a few ... ?)
>>
>> Just wondering on the good setup in that kind of situation
>>
>> Thx
>> -P
>>
>> -
>>  QmailToaster hosted by: VR Hosted 
>> -
>> To unsubscribe, e-mail: 
[EMAIL PROTECTED]
>> For additional commands, e-mail: 
[EMAIL PROTECTED]

>>
>>
>
> -
> QmailToaster hosted by: VR Hosted 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: 
[EMAIL PROTECTED]

>


-
 QmailToaster hosted by: VR Hosted 
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
QmailToaster hosted by: VR Hosted 
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
QmailToaster hosted by: VR Hosted 
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [qmailtoaster] SRS with multi frontend smtp

[Erik Espinoza]

Philip,

I don't know how you have everything configured, so I can't tell you
how to run your infrastructure.

As far as multiple entries, I'd recommend doing  srs1.yourdomain.com
for the first box, srs2.yourdomain.com and srs3 and so forth. Unless
they are running in a clustered configuration.

Thanks,
Erik

On 1/27/07, Philip Nix Guru <[EMAIL PROTECTED]> wrote:

Forgot one thing :)
the srs.yourdoamin MX record should point to the server hosting the real
users or it can point to the MX with the lower priorities ?
and can you set as many MX entries as you want ?
Thx again for the help
Cheers
-P


Erik Espinoza wrote:
> Hey Phil,
>
> Set SRS on the machine that has real users. If both machines have real
> users, set SRS up on both.
>
> Don't use the same srs_domain/srs_secret unless both machines are
> running in a clustered config.
>
> Erik
>
> On 1/27/07, Philip Nix Guru <[EMAIL PROTECTED]> wrote:
>> Hello
>> I was just thinking 
>> If you have lets say a couple of frontend smtp servers filtering emails
>> before delivering (smtproute) to some other qtoaster machines holding
>> your mailboxes.
>> How would you implement SRS ? If you send an email with  machine B
>> (where you have mailboxes and srs configured), you change your envelope
>> sender address of your outgoing message and if then the email gets
>> bounced but goes through another smtp (frontend),
>> machine A (the filtering machine) .
>> How would that work ?
>>
>> You should set exactly same SECRET on all machines or by having
>> smtproute configured for that domain the srs check would get by passed ?
>> or maybe point srs.YOURDOMAIN mx record to the machine used for sending
>> ? (if you got a few ... ?)
>>
>> Just wondering on the good setup in that kind of situation
>>
>> Thx
>> -P
>>
>> -
>>  QmailToaster hosted by: VR Hosted 
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
> -
> QmailToaster hosted by: VR Hosted 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>


-
 QmailToaster hosted by: VR Hosted 
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
QmailToaster hosted by: VR Hosted 
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [qmailtoaster] SRS with multi frontend smtp

[Philip Nix Guru]

Forgot one thing :)
the srs.yourdoamin MX record should point to the server hosting the real 
users or it can point to the MX with the lower priorities ?

and can you set as many MX entries as you want ?
Thx again for the help
Cheers
-P


Erik Espinoza wrote:

Hey Phil,

Set SRS on the machine that has real users. If both machines have real
users, set SRS up on both.

Don't use the same srs_domain/srs_secret unless both machines are
running in a clustered config.

Erik

On 1/27/07, Philip Nix Guru <[EMAIL PROTECTED]> wrote:

Hello
I was just thinking 
If you have lets say a couple of frontend smtp servers filtering emails
before delivering (smtproute) to some other qtoaster machines holding
your mailboxes.
How would you implement SRS ? If you send an email with  machine B
(where you have mailboxes and srs configured), you change your envelope
sender address of your outgoing message and if then the email gets
bounced but goes through another smtp (frontend),
machine A (the filtering machine) .
How would that work ?

You should set exactly same SECRET on all machines or by having
smtproute configured for that domain the srs check would get by passed ?
or maybe point srs.YOURDOMAIN mx record to the machine used for sending
? (if you got a few ... ?)

Just wondering on the good setup in that kind of situation

Thx
-P

-
 QmailToaster hosted by: VR Hosted 
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
QmailToaster hosted by: VR Hosted 
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
QmailToaster hosted by: VR Hosted 
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [qmailtoaster] SRS with multi frontend smtp

[Philip Nix Guru]

Hello Erik
Thx for the info

Erik Espinoza wrote:

Hey Phil,

Set SRS on the machine that has real users. If both machines have real
users, set SRS up on both.

Don't use the same srs_domain/srs_secret unless both machines are
running in a clustered config.

Erik

On 1/27/07, Philip Nix Guru <[EMAIL PROTECTED]> wrote:

Hello
I was just thinking 
If you have lets say a couple of frontend smtp servers filtering emails
before delivering (smtproute) to some other qtoaster machines holding
your mailboxes.
How would you implement SRS ? If you send an email with  machine B
(where you have mailboxes and srs configured), you change your envelope
sender address of your outgoing message and if then the email gets
bounced but goes through another smtp (frontend),
machine A (the filtering machine) .
How would that work ?

You should set exactly same SECRET on all machines or by having
smtproute configured for that domain the srs check would get by passed ?
or maybe point srs.YOURDOMAIN mx record to the machine used for sending
? (if you got a few ... ?)

Just wondering on the good setup in that kind of situation

Thx
-P

-
 QmailToaster hosted by: VR Hosted 
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
QmailToaster hosted by: VR Hosted 
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
QmailToaster hosted by: VR Hosted 
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [qmailtoaster] setting noreplace more in *-toaster.specs

[Erik Espinoza]

> These too are definitely config files (the .pre extension simply means they 
are loaded before other .cf files). 7 lines are different in mine than those 
distributed (i.e. I've enabled 7 plugins). A normal spamassassin upgrade with 
never overwrite files in /etc/mail/spamassassin, so we shouldn't either.

These should definitely be tagged as noreplace in the spec file. Permanently. ;)


I put all of my custom conifg in myconfig.cf. It's easier that way,
just a thought.


>> The wiki instructions for SURBL say to
>> modify v310.pre to add the loading of URIDNSBL. Couldn't this be included in
>> the stock toaster without changing its behavior (given the -L switch)? I
>> think this would be desirable to have in the stock toaster.
>
> I'm not sure if URIDNSBL is enabled by -L.

"-L" says to use only local rules, which *disables* URIDNSBL, along with
other rules that require internet connectivity to operate. I believe this
flag is intended for stand-alone SA implementations. I don't think it's
generally a good option for the toaster. My guess is that it is intended to
'protect' a toaster that doesn't have caching DNS set up properly.


"-L" has been removed as a default for a long time now.

Erik

-
QmailToaster hosted by: VR Hosted 
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [qmailtoaster] SRS with multi frontend smtp

[Erik Espinoza]

Hey Phil,

Set SRS on the machine that has real users. If both machines have real
users, set SRS up on both.

Don't use the same srs_domain/srs_secret unless both machines are
running in a clustered config.

Erik

On 1/27/07, Philip Nix Guru <[EMAIL PROTECTED]> wrote:

Hello
I was just thinking 
If you have lets say a couple of frontend smtp servers filtering emails
before delivering (smtproute) to some other qtoaster machines holding
your mailboxes.
How would you implement SRS ? If you send an email with  machine B
(where you have mailboxes and srs configured), you change your envelope
sender address of your outgoing message and if then the email gets
bounced but goes through another smtp (frontend),
machine A (the filtering machine) .
How would that work ?

You should set exactly same SECRET on all machines or by having
smtproute configured for that domain the srs check would get by passed ?
or maybe point srs.YOURDOMAIN mx record to the machine used for sending
? (if you got a few ... ?)

Just wondering on the good setup in that kind of situation

Thx
-P

-
 QmailToaster hosted by: VR Hosted 
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
QmailToaster hosted by: VR Hosted 
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [qmailtoaster] setting noreplace more in *-toaster.specs

[Eric \"Shubes\"]

Quinn Comendant wrote:
> On Thu, 25 Jan 2007 19:22:30 -0700, Eric "Shubes" wrote:
>>> %{qdir}/supervise/spamd/run
>> I don't think of this as a configuration file. [...]
> 
> It's not really a "configuration file" but because it is something that might 
> be fine-tuned there is a strong advantage to adding the %config(noreplace) 
> flag in the rpm spec. By doing so we only ensure that upgrades will not 
> overwrite this file if it is changed. The drawback is that if this file *is* 
> modified as in a new version, the new copy will not be installed immediately, 
> instead it will be installed in the same location with a .rpmnew extension 
> (and a message printed to screen during install). The user will then need to 
> compare their modified file (run) with the .rpmnew file (run.rpmnew). But 
> this gives them the chance to merge the upgrade changes with their own 
> modifications.

Yes, it's not really a configuration file, yet it contains configuration
data. That is the crux of the problem as I see it. I believe that the proper
solution is to remove the configuration components from the file and put
them where they belong. Making this file a config(noreplace) type is a short
term quick fix, that will create problems in the long term. For instance,
what happens when there's a change to the run file that is required for
proper operation (however unlikely that may be)? I suppose for that release
it'll need to be an rpmsave (and another change to the spec file).

>> As recently discussed on the
>> this list, I think it'd be good if the toaster had
>> /var/qmail/control/supervise/${service}/concurrent (or some such) control
>> files where tailoring of tcpserver parameters would be specified. These
>> control files, when present, should then be specified as %config(noreplace).
>> In the case of spamd, the -L switch should be tailorable. So there might be
>> a /var/qmail/control/supervise/spamd/switches file, which would contain
>> "-L", and the corresponding run file would include in the exec command line
>> if the "switches" file exists.
> 
> I think that's really too much complexity and it makes it harder for 
> everybody. How many control files would be needed to customize spamd the way 
> I'm running it, which is:
> 
> exec /usr/bin/spamd -q -x -u vpopmail -s stderr -P -m 15 --min-spare=2 
> --max-spare=5 --max-conn-per-child=50 --timeout-child=20 --timeout-tcp=20 2>&1

As few as one control file if it's done as I described above, with a single
"switches" file.

Keep in mind, the project objective is to make things easy for a non-admin
type user, not so much an experienced administrator. That's why there is
already a concurrencyincoming control file. I'm simply suggesting that we
move the toaster more in that direction. It is a lot less likely that an
inexperienced admin will screw up the run file this way, and having them
separated will also make it much easier to write a web app for maintaining
them (wouldn't you like to see that?). Besides which, separating parameters
from the code is simply a good programming practice (for many reasons I
won't go into further here).

>>> %{_sysconfdir}/mail/spamassassin/v310.pre
>>> %{_sysconfdir}/mail/spamassassin/v312.pre
>> I'm not so sure about these two.
> 
> These too are definitely config files (the .pre extension simply means they 
> are loaded before other .cf files). 7 lines are different in mine than those 
> distributed (i.e. I've enabled 7 plugins). A normal spamassassin upgrade with 
> never overwrite files in /etc/mail/spamassassin, so we shouldn't either.

These should definitely be tagged as noreplace in the spec file. Permanently. ;)

>> The wiki instructions for SURBL say to
>> modify v310.pre to add the loading of URIDNSBL. Couldn't this be included in
>> the stock toaster without changing its behavior (given the -L switch)? I
>> think this would be desirable to have in the stock toaster.
> 
> I'm not sure if URIDNSBL is enabled by -L.

"-L" says to use only local rules, which *disables* URIDNSBL, along with
other rules that require internet connectivity to operate. I believe this
flag is intended for stand-alone SA implementations. I don't think it's
generally a good option for the toaster. My guess is that it is intended to
'protect' a toaster that doesn't have caching DNS set up properly.

> But then again, there are so many different permutations I think the best 
> option is simply providing stock spamassassin configuration files and assume 
> the installing sysadmin will know what he needs (or ask the spamassassin list 
> for advice).

One size definitely does not fit all. However, as you, the experienced
administrator, find useful settings, I'd expect that other toaster users
would probably find at least some of these settings useful too. The toaster
project goal is to be preconfigured as much as possible, in a way that will
benefit and be suitable to the most users. I don't think that stock SA
fulfills this goal.


-- 
-Eric 'shubes'

---

Re: [qmailtoaster] copying users/domains on a different server with different IP

[Alexey Loukianov]

Warren (mailing lists) wrote:
You forgot to also sync MySQL vpopmail database, which cannot be done 
as a simple rsync. Consider using database replication feature of 
MySQL, or care about setting up dump-rsync-restore script for this task.

If you do not have binary logging turned on, rsync will work just fine.


Hmm... Tell me please, how does binlogs, written to entirely different 
files than DB ones will disturb you?


Also, what are you going to rsync? MySQLs data dir? Ok, that will do in 
case you store tables in MyISAM tablespace, but will not work in case of 
InnoDB. Also, rsyncing MyISAMi tables 'on the fly' in not officially 
supported method by MySQL.Net, and thus it might lead to unpredictable 
consequences like loosing part of users, corrupted tables on slave 
server, etc. I think that it's wiser to use officially supported methods 
of MySQL database replications instead of simple rsync.


--
Best regards,
Alexey Loukianov  mailto:[EMAIL PROTECTED]
System Engineer,
IT Department,
Lavtech Corp.

-
QmailToaster hosted by: VR Hosted 
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[qmailtoaster] SRS with multi frontend smtp

[Philip Nix Guru]

Hello
I was just thinking 
If you have lets say a couple of frontend smtp servers filtering emails 
before delivering (smtproute) to some other qtoaster machines holding 
your mailboxes.
How would you implement SRS ? If you send an email with  machine B 
(where you have mailboxes and srs configured), you change your envelope 
sender address of your outgoing message and if then the email gets 
bounced but goes through another smtp (frontend),

machine A (the filtering machine) .
How would that work ?

You should set exactly same SECRET on all machines or by having 
smtproute configured for that domain the srs check would get by passed ?
or maybe point srs.YOURDOMAIN mx record to the machine used for sending 
? (if you got a few ... ?)


Just wondering on the good setup in that kind of situation

Thx
-P

-
QmailToaster hosted by: VR Hosted 
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]