On Tue, 2002-11-19 at 22:17, Darrell May wrote:
>
> Rasjid Wilcox <[EMAIL PROTECTED]> said:
>
> > Gordon is right. There is not need to worry about mailrules on local
> > interfaces.
>
> If you think about it, there is tremendous possibles if you can define
> separate internal and external rule
Jon Blakely - CTS Howick <[EMAIL PROTECTED]> said:
> the culprit is
>
> e-smith-mailfront-0.3.7-01.noarch.rpm
>
> This is from 5.6 right and 5.6 uses iptables
Excellent Jon! Thank you VERY much for not only testing but further
troubleshooting and diagnosing the problem. I'll update/rebuild tha
#x27;smtpfront-qmail'}{'access'} || "public";
$OUT = allow_tcp_in(25,
($status eq "enabled") && ($access eq "public"));
}
Jon
> -Original Message-----
> From: Darrell May [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, No
Jon Blakely - CTS Howick <[EMAIL PROTECTED]> said:
> I have just tried your alpha contrib. I am no longer receiving external
> e-mail, it is piling up at my backup mx. Internal is fine.
As I reported in my initial post:
http://www.mail-archive.com/devinfo@lists.e-smith.org/msg10727.html
As su
On Wed, 20 Nov 2002, Darrell May wrote:
>
> Charlie Brady <[EMAIL PROTECTED]> said:
>
> > You might want to check what "joe" here means. It's documented at:
> >
> > http://cr.yp.to/proto/ucspi-tcp.txt
>
> 'TCPREMOTEINFO, if possible: the result of a 931/1413/IDENT/TAP query'
You can't trust th
On Wed, Nov 20, 2002 at 09:05:16PM -, Darrell May <[EMAIL PROTECTED]> wrote:
>
> Charlie Brady <[EMAIL PROTECTED]> said:
>
> > You might want to check what "joe" here means. It's documented at:
> >
> > http://cr.yp.to/proto/ucspi-tcp.txt
>
> 'TCPREMOTEINFO, if possible: the result of a 931/1
Charlie Brady <[EMAIL PROTECTED]> said:
> You might want to check what "joe" here means. It's documented at:
>
> http://cr.yp.to/proto/ucspi-tcp.txt
'TCPREMOTEINFO, if possible: the result of a 931/1413/IDENT/TAP query'
IIUC this returns system not user info.
Thanks Charlie,
--
Darrell May
D
On Wed, 20 Nov 2002, Darrell May wrote:
> If $TCPREMOTEIP is 127.0.0.1 and $TCPREMOTEINFO is joe, tcpserver will
> follow the first instructions.
>
> So 'possibly' if we expand on this we could have as one example:
>
> [EMAIL PROTECTED]:allow,RELAYCLIENT="",MAILRULES="/var/qmail/control/mailrul
Nick Ramsay <[EMAIL PROTECTED]> said:
> Doesn't this require a bit more trickery to associate IP addresses
> with user accounts?
Good question Nick. I don't know for sure. Bear with me as I'm trying to
gather all the information and decipher it. Many thanks to those that have
shared informati
On Wed, Nov 20, 2002 at 06:30:18AM -, Darrell May <[EMAIL PROTECTED]> wrote:
>
> Gordon Rowell <[EMAIL PROTECTED]> said:
>
> > So, tcpserver can be used (as we do)
>
> Thanks Gordon, your explanation really helps. A google search led me to
> this page which explains further about tcpserver:
Gordon Rowell <[EMAIL PROTECTED]> said:
> So, tcpserver can be used (as we do)
Thanks Gordon, your explanation really helps. A google search led me to
this page which explains further about tcpserver:
http://www.die.net/doc/linux/man/man1/tcpserver.1.html
Regards,
--
Darrell May
DMC Netsourc
Rasjid Wilcox <[EMAIL PROTECTED]> said:
> Gordon is right. There is not need to worry about mailrules on local
> interfaces.
If you think about it, there is tremendous possibles if you can define
separate internal and external rules. I think we are all on the same page
about blocking external i
> -Original Message-
> From: Gordon Rowell [mailto:[EMAIL PROTECTED]]
> I'm not clear why you're trying to impose relay rules on the local
> interface(s).
Gordon is right. There is not need to worry about mailrules on local
interfaces. I have not looked at SME 5.6 yet, but I imagine that
On Tue, Nov 19, 2002 at 10:04:33PM -0500, Gordon Rowell <[EMAIL PROTECTED]>
wrote:
> [...]
> That's precisely what the last line above is asking _tcpserver_ to do -
> select a MAILRULES file. The other lines don't bother with MAILRULES,
> since we're going to let them relay anyway.
>
> tcpserver s
On Wed, Nov 20, 2002 at 02:45:13AM -, Darrell May <[EMAIL PROTECTED]> wrote:
> [...]
> # cat /etc/tcprules/tcp.smtp
> 127.0.0.1:allow,RELAYCLIENT=""
> 192.168.1.10:allow,RELAYCLIENT=""
> 192.168.1.:allow,RELAYCLIENT=""
> :allow,MAILRULES="/var/qmail/control/mailrules.default"
> [...]
> I'm com
Rasjid Wilcox <[EMAIL PROTECTED]> said:
> and the other lines say
> ...:allow,MAILRULES="/etc/mailrules/external.rules"
>
> I think that will do the trick.
That's certainly helping fill in the gaps :-)
I'll just add that Mitel is templated so what you need to look at is
actually the templated f
erty
> Cc: Devinfo
> Subject: Re: [e-smith-devinfo] [ALPHA] mailrules for SME5.5 available
> [was Possible mailfront replacement]
>
>
>
> Charlie Brady <[EMAIL PROTECTED]> said:
>
> > True, but the ruleset is entirely up to you. The rules file used is
> > c
Hi Darrell,
> If anyone from Mitel or devinfo has the time and would like to offer
> further assistance in my efforts to develop an effective mailfront
> mailrules contrib, please let me know.
We would happily help you with this contrib but we are in the middle of
incorporating our company i
Charlie Brady <[EMAIL PROTECTED]> said:
> No.
Understood.
If anyone from Mitel or devinfo has the time and would like to offer further
assistance in my efforts to develop an effective mailfront mailrules
contrib, please let me know.
Regards,
--
Darrell May
DMC Netsourced.com
http://myEZserver
On Tue, 19 Nov 2002, Darrell May wrote:
> Charlie Brady <[EMAIL PROTECTED]> said:
>
> > True, but the ruleset is entirely up to you. The rules file used is
> > configurable via an environment variable, and can be set differently
> > depending on originating IP address.
>
> Charlie, I'd very muc
Charlie Brady <[EMAIL PROTECTED]> said:
> True, but the ruleset is entirely up to you. The rules file used is
> configurable via an environment variable, and can be set differently
> depending on originating IP address.
Charlie, I'd very much appreciate it if you would further share your
experti
On Tue, 19 Nov 2002, Rich Lafferty wrote:
> On Tue, Nov 19, 2002 at 07:22:21PM -, Darrell May <[EMAIL PROTECTED]> wrote:
> >
> > Further testing has proven '*@*' does not work either :-< This blocks
> > sending to undefined external addresses. The '*' magical implementation is
> > a pain b
On Tue, Nov 19, 2002 at 07:22:21PM -, Darrell May <[EMAIL PROTECTED]> wrote:
>
> Rich Lafferty <[EMAIL PROTECTED]> said:
>
> > Yeah, I see why the feature exists, and it's useful -- but I'd still
> > have preferred a different directive for sender rules instead of
> > making "*" magical. (Hav
23 matches
Mail list logo