[This is a courtesy copy of an article posted to Usenet via Deja News]
HI All...
Question about smail "secruity violation" error message...
( I hope this dejanews posting works )...
First off wrt compling smail-3.2.0.96... yeah I had that same compile
error with HSTR_ERROR...I temporarily/quick kludged it too by taking out
the second duplicate error case statement in my version.
But, I have noticed a new different problem that I did not have before...
that of sending email to:
BTW: running majordomo-1.94.1 to handle "info@" on Linux-2.0.30 on
PentPro-200Mhz..
[a_legal_domain]# elm -s "testing info" info@Another_Domain.org <
/dev/null
worked fine for smail-3.2.0.90 but causes the following error for
smail-3.2.0.96:
If I revert back to smail*.90 everything works again...
*********************************************************************
timestamp remote a_legal_domain[ip]: '<info@another_domain.org>'
<info@another_domain.org> recipient not matched: security violation:
remote address not permitted
**********************************************************************
Does anyone know what the new option is that needed to be specified to
prevent this "security violation" ??
thanx
alvin@Linux-Consulting.com
BTW...I used the smail-3.2.0.96/conf/EDITME that is listed on my pags:
http://www.linux-consulting.com/FAQ_virtual
In article
<Pine.LNX.3.96.970607194152.28020D-100000@calvin.oriole.sbay.org>,
George Bonser <grep@oriole.sbay.org> wrote:
>
>
> I had some trouble getting the latest beta to compile on Debian 1.3 using
> 2.0.30 Linux. A reader of the smail users mailing list sent me this patch
> that did the trick in getting it to compile. The patch has been forwarded
> with a bug report so it should be incorporated in the source (hopefully).
> In the meantime, anyone with Linux wishing to test the new beta will need
> this. The author's email address has been removed to prevent his being
> spammed.
>
> Posted with author's permission.
>
> George Bonser
> grep@oriole.sbay.org, grep@concentric.net
>
> ---------- Forwarded message ----------
> Date: Sat, 7 Jun 1997 08:44:13 -0700 (PDT)
> From: Craig Harmer <removed to squash spambots on usenet>
> To: George Bonser <grep@oriole.sbay.org>
> Subject: Re: Unidentified subject!
>
> i don't know about the second problem, but i submitted a bug report and
> a fix for your first problem. here is the bug report, complete with
> a patch script:
>
> >Date: Thu, 5 Jun 1997 19:24:58 -0700 (PDT)
> >Subject: compile problems with hstrerror() and older versions of bind
>
> >Submitter-Id: net
> >Originator: craig harmer
> >Organization:
>
> craig harmer PGP public key available:
>
> >Confidential: no
> >Synopsis: problems using hstrerror() and NEED_HSTRERROR
> >Severity: serious
> >Priority: medium
> >Category: smail-bugs
> >Class: sw-bug
> >Release: 3.2.0.96
> >Environment:
> System: Linux ns 1.3.100 #7 Thu May 8 13:40:00 PDT 1997 i586
> Architecture: i586
>
> >Description:
> On some versions of Linux, the version of BIND shipped with the system
> is old enough that it does not provide the hstrerror() function. When
> the built in hstrerror() function is enabled by setting NEED_HSTRERROR
> the compilation fails because two error return values turn out to have
> the same value and gcc chokes on the switch statement.
>
> because these values are defined:
>
> #define NO_DATA 4 /* Valid name, no data record of requested type */
> #define NO_ADDRESS NO_DATA /* no address, look for MX record */
>
> the straightforward fix of saying:
>
> #if NO_DATA != NO_ADDRESS
> case NO_DATA:
> ...
> #endif
>
> doesn't work. the comparision must be done in C.
>
> also, the NEED_HSTRERROR define is not documented in `conf/EDITME-dist' or
> `conf/os/template'. it would be helpful for naive users such as myself
> if it were.
>
> >How-To-Repeat:
>
> put:
>
> MISC_DEFINES=NEED_HSTRERROR
>
> in conf/EDITME and attempt to compile on Slackware Linux 2.3 or
> Redhat Linux 4.1.
>
> note that Redhat Linux 4.1 appears to have a version of named built from
> BIND-4.9.4-P1, but the C library still doesn't include the `hstrerror()'
> function.
>
> >Fix:
>
> here's a patch to fix the problem and add documentation to conf/EDITME-dist.
>
> --- OLD/conf/EDITME-dist 1997/06/03 17:38:01 1.1
> +++ conf/EDITME-dist 1997/06/06 01:58:35
> @@ -413,6 +413,14 @@
> # driver, on some versions of the resolv library, so beware. If bind
> # doesn't work for you, try defining OBSOLETE_RESOLVER.
> #
> +# If you have compilation problems where there is an undefined reference
> +# to hstrerror, then add NEED_HSTRERROR to MISC_DEFINES. That will
> +# enable the compilation of a private hstrerror() functions. This is
> +# required, at least, on Linux Slackware 2.3 and Linux Redhat 4.1 systems
> +# when using an older version of bind. Despite the fact that Redhat 4.1
> +# has a `named' built with BIND-4.9.4-P1, the C library seems to have an
> +# older version of the resolver routines.
> +#
> #
> # IMPORTANT FOR USERS OF SOME SEQUENT OS RELEASES
> #
> --- OLD/src/smtprecv.c 1997/06/03 17:38:01 1.1
> +++ src/smtprecv.c 1997/06/06 02:05:28 1.2
> @@ -1439,7 +1439,7 @@
> int h_err;
> {
> /* XXX Should use h_errlist if it's available */
> - switch (h_errno) {
> + switch (h_err) {
> case 0:
> return "Resolver Error 0 (no error)";
>
> @@ -1455,10 +1455,23 @@
> case NO_RECOVERY:
> return "Unknown server error";
>
> - case NO_ADDRESS:
> - return "No address associated with name";
> -
> default:
> +
> + /*
> + * In some (all?) older release of bind that don't provide
> + * hstrerror() the value NO_ADDRESS is the same as NO_DATA, and
> + * gcc complains if the same value exists in in different case
> + * statements. So we use this work around to test for a unique
> + * value of NO_ADDRESS. Hopefully the compiler will optimize
> + * the expression. This can't be done in the pre-processor.
> + * This is required when compiling with Slackware Linux 2.3 and
> + * Redhat Linux 3.1, at least. bind-4.9.3-BETA9 supplies the
> + * function.
> + */
> +
> + if (NO_DATA != NO_ADDRESS && h_err == NO_ADDRESS) {
> + return "No address associated with name";
> + }
> return "Unknown resolver error";
> }
> /* NOTREACHED */
>
> cheers,
>
> craig.
-------------------==== Posted via Deja News ====-----------------------
http://www.dejanews.com/ Search, Read, Post to Usenet
|
|
