You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Mike Loiterman <mi...@ascendency.net> on 2005/09/20 02:31:11 UTC

Missing socket file for spamd

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

When I ty to have procmail engage the spamd binary, I get this error in my
maillog.
 
Sep 19 19:25:53 eisenhower spamc[640]: connect(AF_UNIX) to spamd
/tmp/spamd.sock failed: Socket operation on non-socket 

I tried touching a file called spamd.sock and chmoding it to 777 but that
doesn't work.  How can I create the socket file or have spamd create one for
me?

- ------------------------------
Mike Loiterman
grantADLER
Tel: 630-302-4944
Fax: 773-442-0992
Email: mike@ascendency.net
PGP Key: 0xD1B9D18E


-----BEGIN PGP SIGNATURE-----
Version: PGP Desktop 9.0.2 (Build 2424)
Comment: Secured by PGP 9.0.2

iQA/AwUBQy9YUmjZbUnRudGOEQJ4XwCgiTA7zMtyXtm77+iLmtEwk08rZ0QAn2Rn
rCzV+K2vGDXnwDxPvtdJjEvK
=itgS
-----END PGP SIGNATURE-----

Re: Missing socket file for spamd

Posted by jdow <jd...@earthlink.net>.
From: "Mike Loiterman" <mi...@ascendency.net>

> When I ty to have procmail engage the spamd binary, I get this error in my
> maillog.
>
> Sep 19 19:25:53 eisenhower spamc[640]: connect(AF_UNIX) to spamd
> /tmp/spamd.sock failed: Socket operation on non-socket
>
> I tried touching a file called spamd.sock and chmoding it to 777 but that
> doesn't work.  How can I create the socket file or have spamd create one 
> for
> me?

Delete the file spamd.sock.

Now run spamd. Depending on your distribution this procedure will vary.
For Mandrake and RedHat you use the command "service spamassassin start"
from a command prompt. Or from the gui you somehow start the spamassassin
service, which runs spamd. Spamd creates the socket to which spamc then
connects.

{^_^} 



Re: Postfix/SA/Exchange 2000 'NDR attack' exploit spam and other bad things

Posted by Ralf Hildebrandt <Ra...@charite.de>.
* Greg Allen <sa...@floridacpu.com>:

> There is also apparently little to nothing that can be done for the
> exchange server. There are a few third party items that I am looking
> into, but the real fix (supposedly) is to upgrade to Exchange 2003. See
> here: http://support.microsoft.com/?kbid=886208

You can use that:
http://postfix.state-of-mind.de/patrick.koetter/mailrelay/

-- 
Ralf Hildebrandt (i.A. des IT-Zentrums)         Ralf.Hildebrandt@charite.de
Charite - Universitätsmedizin Berlin            Tel.  +49 (0)30-450 570-155
Gemeinsame Einrichtung von FU- und HU-Berlin    Fax.  +49 (0)30-450 570-962
IT-Zentrum Standort CBF                 send no mail to spamtrap@charite.de

Re: Postfix/SA/Exchange 2000 'NDR attack' exploit spam and other bad things

Posted by Jay Plesset <ja...@dp-design.com>.
Wow.  I knew I didn't like Exchange.. .

I run Sun's Messaging Server 6.2.  SA integrates right into it, with 
hooks provided by Sun.

Addresses are first verified, even before the sending system gets to the 
"data" part of the conversation.  If the address is bogus, they get a 
550 5.1.1 unkown alias rejection, right there.  Then the message goes to 
SA for processing...

Sun Java Messaging Server runs on many OS's, and is a free download, to 
try.  They'd like you to pay for a license...

jay

Greg Allen wrote:

>I have recently been working on the Exchange 2000 NDR attack issue.
>
>For those who are not aware of this issue, I will explain.
>
>It seems there is a certain group of desperate idiot spammers that believe
>that bouncing off good Exchange 2000 servers with non-delivery reports is a
>good way to deliver spam.
>
>They send tons of email at your Exchange 2000 server, with a different reply
>addresses forged for each email.
>
>The spam recipient apparently sees an NDR from your server, with spam
>attached. Your server did the delivery. (ooops) Moronic idea, must look like
>hell to the spam recipient, but apparently it is being done out there.
>
>There is also apparently little to nothing that can be done for the exchange
>server. There are a few third party items that I am looking into, but the
>real fix (supposedly) is to upgrade to Exchange 2003. See here:
>http://support.microsoft.com/?kbid=886208
>
>The thing that apparently is the tip off for this issue is tons of queued up
>email to spam domains in your Exchange queues.
>
>The difficult part, it that it is hard to tell the difference between NDR
>attacks on your Exchange server as opposed to some idiot just using your
>domain for his reply address in a spam run. It has about the same affect as
>far as I can tell with the queues.
>
>Ok, that is the background...
>
>Now onto the problem as I see it. Let's say I do the fix with 2003 (which I
>have already done). So, recipient verification is now enabled on Exchange
>2003. One small problem however. If I have SpamAssassin kill emails at lets
>say...20 points spam score, the email recipient never gets verified on my
>front end Postfix/SA server. I am receiving all the various bogus email
>addresses and sending them to the trash can where they belong.
>
>What would be better though, is for Postfix/SA to allow recipient
>verification to Exchange before Postfix/SA starts going to work at all. I
>would rather not make recipient files on the postfix server. Seems like
>there should be a better way.
>
>It would seem that ideally, the error "User unknown (in reply to RCPT TO
>command)" (or whatever) should be allowed to happen before SA starts testing
>the email.
>
>I could just let the high score emails go through without killing it, and
>that would probably work correctly as far as recipient verification goes
>with the Exchange 2003 server, but I would rather not do that. The legit
>users would see a flood of more  ***spam*** tagged emails than they are used
>to seeing.
>
>So, I guess my question would be, does anyone know of a way to allow a
>natural recipient validation check downstream to the Exchange 2003 server
>before SA starts working, so that SA does not start testing on all these
>bogus email addresses. Again, I am looking for some solution that does not
>involve creating recipient verification maps on the Postfix server.
>
>
>Thanks in advance for any ideas.
>
>
>
>
>
>
>
>
>
>
>
>  
>

Re: Postfix/SA/Exchange 2000 'NDR attack' exploit spam and other bad things

Posted by Stuart Johnston <st...@ebby.com>.
Greg Allen wrote:
> 
> So, I guess my question would be, does anyone know of a way to allow a
> natural recipient validation check downstream to the Exchange 2003 server
> before SA starts working, so that SA does not start testing on all these
> bogus email addresses. Again, I am looking for some solution that does not
> involve creating recipient verification maps on the Postfix server.

With Postfix 2.1 you can do Address Verification: 
http://www.postfix.org/ADDRESS_VERIFICATION_README.html

Postfix/SA/Exchange 2000 'NDR attack' exploit spam and other bad things

Posted by Greg Allen <sa...@floridacpu.com>.
I have recently been working on the Exchange 2000 NDR attack issue.

For those who are not aware of this issue, I will explain.

It seems there is a certain group of desperate idiot spammers that believe
that bouncing off good Exchange 2000 servers with non-delivery reports is a
good way to deliver spam.

They send tons of email at your Exchange 2000 server, with a different reply
addresses forged for each email.

The spam recipient apparently sees an NDR from your server, with spam
attached. Your server did the delivery. (ooops) Moronic idea, must look like
hell to the spam recipient, but apparently it is being done out there.

There is also apparently little to nothing that can be done for the exchange
server. There are a few third party items that I am looking into, but the
real fix (supposedly) is to upgrade to Exchange 2003. See here:
http://support.microsoft.com/?kbid=886208

The thing that apparently is the tip off for this issue is tons of queued up
email to spam domains in your Exchange queues.

The difficult part, it that it is hard to tell the difference between NDR
attacks on your Exchange server as opposed to some idiot just using your
domain for his reply address in a spam run. It has about the same affect as
far as I can tell with the queues.

Ok, that is the background...

Now onto the problem as I see it. Let's say I do the fix with 2003 (which I
have already done). So, recipient verification is now enabled on Exchange
2003. One small problem however. If I have SpamAssassin kill emails at lets
say...20 points spam score, the email recipient never gets verified on my
front end Postfix/SA server. I am receiving all the various bogus email
addresses and sending them to the trash can where they belong.

What would be better though, is for Postfix/SA to allow recipient
verification to Exchange before Postfix/SA starts going to work at all. I
would rather not make recipient files on the postfix server. Seems like
there should be a better way.

It would seem that ideally, the error "User unknown (in reply to RCPT TO
command)" (or whatever) should be allowed to happen before SA starts testing
the email.

I could just let the high score emails go through without killing it, and
that would probably work correctly as far as recipient verification goes
with the Exchange 2003 server, but I would rather not do that. The legit
users would see a flood of more  ***spam*** tagged emails than they are used
to seeing.

So, I guess my question would be, does anyone know of a way to allow a
natural recipient validation check downstream to the Exchange 2003 server
before SA starts working, so that SA does not start testing on all these
bogus email addresses. Again, I am looking for some solution that does not
involve creating recipient verification maps on the Postfix server.


Thanks in advance for any ideas.