Milter-greylist

I tried to run milter-greylist on my x86-64 system, with libspf.
2.0.2 failed with SPF2 (didn't try SPF1)
2.1.3 failed with SPF1 and SPF2.

System: linux 2.6.15.4, debian-testing, x86-64 (Sempron).

When running 2.1.3 with SPF1 in gdb (with -D  -u smmsp) it properly
checks several emails, and then fails with:
milter-greylist: k1MJMoVE009106: skipping greylist because recipient
<jmbvxvbzit.eraro@u\ea.org> is whitelisted,
(from=<MarthaDavidson@ajaccountancy.com>,
rcpt=<jmbvxvbzit.eraro\@...>,
addr=ppp85-140-196-5.pppoe.mtu-net.ru[85.140.196.5})
[Thread 1108621664 (LWP 9107) exited]
milter-greylist: greylist: sigwait returned error: 0
[New Thread 1108621664 (LWP 9114)]
milter-greylist: greylist: sigwait returned error: 0
milter-greylist: greylist: mi_stop=2
milter-greylist: Final database dump
milter-greylist: Exiting

I would like to set breakpoints, but don't know where, I cannot find
where the "mi_stop=1" is printed.

When running 2.0.2 or 2.1.3 with libspf2, I get a segfault.
Running 2.1.3 with libspf2, I get this (from gdb):

=>      SPF_request_query_mailfrom(spf_request, &spf_response);
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1117342048 (LWP 4015)]
0x00002aaaab1a25c0 in memset () from /lib/libc.so.6
(gdb) up
#1  0x00002aaaaabcd5f2 in SPF_record_expand_data () from
/usr/lib/libspf2.so.2

(Haven't yet installed the source of libSPF2 to find where it is).

I'm wondering if these errors are known (with a known fix), or if it's
worth trying to figure out what the segfaults are etc.
And, if so, should I try 2.0.2 or 2.1.3?

Thanks,
joostje

joosteto <joostje@...> wrote:

> I tried to run milter-greylist on my x86-64 system, with libspf.
> 2.0.2 failed with SPF2 (didn't try SPF1)
> 2.1.3 failed with SPF1 and SPF2.

An usual cause of crashes: is your libspf linked against a thread-safe
DNS resolver? 

From the README:
WARNING: milter-greylist is a multithreaded program. The external
functions it uses must be thread-safe. While libspf and libspf_alt
contain only thread-safe code, they use the DNS resolver. By default,
the DNS resolver from libc or libresolv is used. If this resolver 
is not thread-safe, milter-greylist with SPF will quickly crash or
hang.
      
You need to make sure that libspf or libspf_alt are linked against
a thread-safe DNS resolver. For instance, NetBSD-1.6.2 libc-supplied 
resolver is from BIND 4, and it is not thread safe. In order to get
a stable milter-greylist, you need to link with a BIND 8.2 or higher
resolver.
  
When building with libspf_alt-0.4, you might encounter problems if
libbind is only available as a static library. It seems to be the
default with BIND 8, which causes troubles. BIND 9 is fine.

-- 
Emmanuel Dreyfus
Un bouquin en français sur BSD:
http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
manu@...

--- In milter-greylist@yahoogroups.com, manu@... wrote:
>
> joosteto <joostje@...> wrote:
> 
> > I tried to run milter-greylist on my x86-64 system, with libspf.
> > 2.0.2 failed with SPF2 (didn't try SPF1)
> > 2.1.3 failed with SPF1 and SPF2.
> 
> An usual cause of crashes: is your libspf linked against a thread-safe
> DNS resolver? 

I really don't know how to find out:(.
I'm using Bind9 as DNS server, but I suppose the resolver comes from
somewhere else.

I read in the libc6 (gnu libc) FAQ:
  {AJ} The GNU C library uses thread safe functions by default and
libc5 used
  non thread safe versions.  The non thread safe functions have in
glibc the
  suffix `_unlocked', for details check <stdio.h>.  Using  
`putc_unlocked' etc.
  instead of `putc' should give nearly the same speed with bonnie  
(bonnie is a
  benchmark program for measuring disk access).

So I would suppose the thread-safe-ness should be OK (libc6 provides
the libresolv.so.2 library milter-greylist is linked with).

Also, my mailsystem handles about 1 email every 10-60 seconds, and is
idle the rest of the time. So I would have thought that
milter-greylist is unlikely to run into threading problems after only
3 to 5 emails, whitch is what happens every time I try it.

Thanks,
joostje

joosteto <joostje@...> wrote:

> I really don't know how to find out:(.

Run nm on libspf. Do you find res_init, or nres_init?

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@...

Anyone have problems sending email to Verizon?

I'm getting the message:
# mailq
                 /var/spool/mqueue (1 request)
-----Q-ID----- --Size-- -----Q-Time----- ------------Sender/ 
Recipient-----------
k1PIjSIn092590      231 Sat Feb 25 10:45 <me@...>
                  (Deferred: 450 Requested mail action not taken-Try  
later:sv6p)
                                          <user@...>
                 Total requests: 1


When I check the maillog, I see entries like so:

Feb 25 10:45:30 planx milter-greylist: k1PIjU7w092774: addr  
206.46.252.150 from <> to <me@...> delayed for 00:08:00

Feb 25 10:45:30 planx sm-mta[92774]: k1PIjU7w092774: Milter:  
to=<me@...>, reject=451 4.7.1 Greylisting in action, please  
come back in 00:08:00

Feb 25 10:45:30 planx sm-mta[92765]: k1PIjSIn092590:  
to=<user@...>, ctladdr=<me@...> (1001/1001),  
delay=00:00:02, xdelay=00:00:01, mailer=esmtp, pri=30724,  
relay=relay.verizon.net. [206.46.232.11], dsn=4.0.0, stat=Deferred:  
450 Requested mail action not taken-Try later:sv14pub.verizon.net

Feb 25 10:45:30 planx sm-mta[92774]: k1PIjU7w092774: lost input  
channel from sv14pub.verizon.net [206.46.252.150] to MTA-v4 after rcpt

Feb 25 10:45:30 planx sm-mta[92774]: k1PIjU7w092774: from=<>, size=0,  
class=0, nrcpts=0, proto=SMTP, daemon=MTA-v4,  
relay=sv14pub.verizon.net [206.46.252.150]


This appears to me, to be an endless loop. Verizon won't accept my  
email unless, I accept theirs... etc.
And since the responding server changes every time I send, milter- 
greylist won't be able to whitelist the verizon server. (I've seen:  
sv25 sv15pub sv2pub sv6pub sv14pub )


Doing a search on the internet I found the following helpful  
explanation:
http://blog.kloppmagic.ca/archives/2005/02/24/verizon-450-requested- 
mail-action-not-taken-try-later-error/

My SPF tag has been set for well over a year... so that didn't solve  
the issue.

I find it odd, that this didn't occur with milter 1.3?, but then  
again... I upgraded to a new server/ip 2 days ago (well after the  
24hr ttl of dns), with the latest and greatest of everything.  
(sendmail, clamav-milter (finally), spam-milter )

For the time being I've whitelisted 206.46.252.142/24
Does anyone have any other ideas?

Thanx,
Bill

Bill Levering wrote:
> Anyone have problems sending email to Verizon?

From the looks of it, Verizon is using a "call back" mechanism, a bit like
milter-sender.

I've not noticed the problem myself, as I only greylist a selective set of
hosts, but it makes sense that greylisting would cause problems with call-back
milters.

--- In milter-greylist@yahoogroups.com, manu@... wrote:
>
> joosteto <joostje@...> wrote:
> 
> > I really don't know how to find out:(.
> 
> Run nm on libspf. Do you find res_init, or nres_init?

Ah, yes, I remember trying that, but without any results (Sorry for
forgetting to mention that). However, after reading the README of the
libc resolver source code, I tried:

/usr/lib$ nm -D libspf2.so|grep res_
                 U __res_nclose
                 U __res_ninit
                 U __res_nquery

(as the readme explained the thread-safe functions are res_n*, instead
of nres_*). Oh, and without the -D argument to nm only outputs "nm:
libspf2.so: no symbols" as the .so doesn't have debug info.


Anyway, I should be thread-safe, shouldn't I?

(The libspf (old spf1) library on my syste does use res_query, so
apparently that one is thread-unsafe, but I see the failures in milter
too when linking with the thread-safe spf2).

Is there anything I can do? This machine may be somewhat special as
it's a amd 64 (x86-64) system (uses 64bit pointers, 32bit int), maybe
it's related?

milter-greylist is currently running without SPF, and really doing a
great job. But I would realy like it if I could let the SPF-OKed
messages go straight through.

Thanks,
joostje

http://www2.verizon.net/micro/whitelist/

On Sat, Feb 25, 2006 at 11:27:00AM -0800, Bill Levering wrote:
> Anyone have problems sending email to Verizon?

[...]

> This appears to me, to be an endless loop. Verizon won't accept my  
> email unless, I accept theirs... etc.
> And since the responding server changes every time I send, milter- 
> greylist won't be able to whitelist the verizon server. (I've seen:  
> sv25 sv15pub sv2pub sv6pub sv14pub )

Yes, this is their silly callback-system which doesn't understand temp
fails.  I filled out the form at:

http://www2.verizon.net/micro/whitelist/

And I never saw a reply.  But our users stopped complaining and I do
see mail going through to Verizon, but still the occasional temp fail
from their server for load being too high as well as the callback
temp-fail.

Who is in charge of the mail infrastructure at Verizon?  I am
agressively anti-spam, but callback introduces a host of problems of
which intolerance of the RFC requried temp fail is one of them.  They
need a reality check over there...


Matt

-- 
Matthew S. Cramer <mscramer@...>          Office: 717-396-5032
Project Manager, Planning and Service Management    Fax:    717-396-5590
Armstrong World Industries, Inc.                    Cell:   717-917-7099

Does this option from greylist.conf not help? # This option attempts to make milter-greylist more # friendly with sender callback systems. When the # message

On Fri, Mar 03, 2006 at 12:43:16PM -0900, Pete 'Wolfy' Hanson wrote:
> Does this option from greylist.conf not help?
> 
> # This option attempts to make milter-greylist more
> # friendly with sender callback systems. When the
> # message is from <>, it will be temporarily
> # rejected at the DATA stage instead of the RCPT
> # stage of the SMTP transaction. In the case of a
> # multi recipient DSN, whitelisted recipient will
> # not be honoured.
> delayedreject

Somehow I never noticed that, but will certainly try and see!


Thanks,

Matt

-- 
Matthew S. Cramer <mscramer@...>          Office: 717-396-5032
Project Manager, Planning and Service Management    Fax:    717-396-5590
Armstrong World Industries, Inc.                    Cell:   717-917-7099

I ran into this same issue a few months ago.  I can confirm that setting
'delayreject' will fix Verizon mail delivery issues.

-----Original Message-----
From: milter-greylist@yahoogroups.com
[mailto:milter-greylist@yahoogroups.com] On Behalf Of Matthew S. Cramer
Sent: Friday, March 03, 2006 2:08 PM
To: milter-greylist@yahoogroups.com
Subject: Re: [milter-greylist] Milter-greylist & Verizon

On Fri, Mar 03, 2006 at 12:43:16PM -0900, Pete 'Wolfy' Hanson wrote:
> Does this option from greylist.conf not help?
> 
> # This option attempts to make milter-greylist more # friendly with 
> sender callback systems. When the # message is from <>, it will be 
> temporarily # rejected at the DATA stage instead of the RCPT # stage 
> of the SMTP transaction. In the case of a # multi recipient DSN, 
> whitelisted recipient will # not be honoured.
> delayedreject

Somehow I never noticed that, but will certainly try and see!


Thanks,

Matt

Michael Wallendahl <mwallend@...> wrote:

> I ran into this same issue a few months ago.  I can confirm that setting
> 'delayreject' will fix Verizon mail delivery issues.

Now the nice thing would be to merge settings such as delayreject in the
access list so that it could be set on a per sender IP basis.

-- 
Emmanuel Dreyfus
Publicité subliminale: achetez ce livre!
http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
manu@...