-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com] On Behalf Of
Lennon - Orcon
Sent: woensdag 23 februari 2005 11:06
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: Re: [spf-discuss] Email Forwarder's Protocol ( EFP )
At any rate, I added a few lines to SPF socketmap to
prevent any SPF stuff being done when the domain does not
exist/does not resolve; and you can find the updated version at:
http://srs-socketmap.info/spf/SPF-socketmapd.0.28.tar.gz
Updated now..
and correctly..
Feb 23 22:50:50 dbmail-mx4 sm-mta[25208]: j1N9omeF025208:
ruleset=check_mail, arg1=<curtm(_at_)wrldnet(_dot_)net>,
relay=[210.221.37.156],
reject=553 5.1.8 <curtm(_at_)wrldnet(_dot_)net>... Domain of sender address
curtm(_at_)wrldnet(_dot_)net does not exist
but (dunno if this is broken or what)..
an email came thru
Had:
Return-path: SRS0=PtJo=RF=XXX(_dot_)XXX=YYY(_at_)bounce2(_dot_)pobox(_dot_)com
Received-spf: none (integer.pobox.com: domain of XXX(_at_)ZZZZZ does not
designate permitted sender hosts)
X-SPF-Guess: pass (seems reasonable for XXXX(_at_)YYY to mail
through K.K.K.K)
I presume it already had a Recieved-spf header in it..
Yes. As you can tell, "$j" in the Received-SPF header is
"integer.pobox.com". So it is their Received-SPF header.
so it
won't add another one like you said in a few emails before.
Not without adding the ONE config line to sendmail/conf.c, no.
Better to make it add X-Received-SPF at the moment on this
side (or hack the sendmail source?)
The problem is, of course, that when everyone uses X-Received-SPF instead,
you wind up having the exact same problem. :)
1 more thing..is there _anyway_ to make sendmail continue its job
processing email if the socketmap perl program dies.. it
doesn't like it when it does and will not access emails at all :-(
Should the socket map ever die, then $1 would return the value of what was
parsed to the map, and seriously mess things up. :) I suppose you could
change the line following the SPF rules,
R$* $: $1 $| $>"Local_check_mail" $1
Into:
R$* $: $&f $| $>"Local_check_mail" $&f
As $f is what is evaluated anyway. Then mail would be processed as normal.
But unless you kill -9 the process, I doubt you will ever see SPF
socketmapd die. All I/O routines have an eval{} safety-net around them;
and unless SPF socketmapd would segfault -- and there is not really any
code which could do that -- I would be very surprised if you ever get it
to die. Remember that the SPF socketmap daemon does nothing more than be
in an accept() loop, so as to fork children. At the very, very worse, a
single child could die (although I do not see how). But that would still
not affect the parent process.
I know spf-milter was much more unstable; but it relied on a very shaky
C-to-Perl interface nobody ever improved upon. SPF socketmap is based on
IO::Socket::UNIX, an age-old, stable module. Never say never, of course;
and if you already got it to die, without artificial intervention, then I
hereby wipe the egg off my face. ;) But underneath you would still see
amazement.
- Mark
System Administrator Asarian-host.org
---
"If you were supposed to understand it,
we wouldn't call it code." - FedEx