Re: [spamdyke-users] Spamdyke and Postfix
Hello Mark, Friday, July 6, 2012, 9:41:20 PM, you wrote: MF It does this by connecting to the sender's MX and attempting to send a message to the sender And if the response is something like Greylist please try later? -- Best regards, Niamhmailto:ni...@fullbore.co.uk ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] Is there a way to control the sender DOMAIN against the Auth DOMAIN ?
I had the same problem -- because someone from China is brute-forcing all info@... accounts.. Once they find an easy password, they abuse it with millions of spam.. - wrote code to check everyone's passwords for easyness (?) and forced ppl to change their passwords -- or I changed it for them.. especially PLESK's short form auth is a killer -- they just need to specify info no need for a domain next to it.. -t On 07/07/2012 09:05 PM, Pablo Murillo wrote: Hi Probably, I don´t explain me very well what I try to say I will try with an example: SMTP-AUTH via SD User to auth x...@domain1.com Mail from: x...@domain2.com Both domains are on localdomains How can I control that the outgoing email belongs to the auth domain ? Txs in advance Pablo Murillo ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] Graylist performance
On 7/8/2012 11:00 AM, spamdyke-users-requ...@spamdyke.org wrote: I think that the simplest way of matching up messages would be if the log messages contained the Message-ID field from the email headers. I checked the TODO.txt file, and Frank beat me to the request: Log the Message-ID field so a message can be tracked from delivery to disk. spamdyke will need to add the Message-ID field if needed. Credit goes to Frank SDI. So I'd like to add +1 for this enhancement. Without it, the effectiveness of graylisting cannot be accurately determined A very clever suggestion. My hat is off to both you and Frank! And I second the kudos to Sam for writing/supporting spamdyke. Bucky ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] Graylist performance
Hi, Am 07.07.2012 um 21:01 schrieb Eric Shubert: Looking at the log messages, I see from: (unknown) in some cases. I presume that this is the envelope sender, while the message/internal sender is used for the graylist entries. Hopefully not. I haven't had a look at the code recently, but I'd assume that envelope sender is the graylist relevant address. At least I'd expect it that way, because graylisting shall drop in after EHLO/MAIL FORM/RCPT TO dialog; And I just checked and it worked that way. So there're exactly four information available in this state of mail transfer conversation: - remote ip address / host name - EHLO name - envelope sender - envelope recipient And only these can and should be graylisting relevant. I think that the simplest way of matching up messages would be if the log messages contained the Message-ID field from the email headers. Unless I'm completely wrong this is neither possible (because no message content has been transferred yet), nor sensible. Imagine - sender tries to send message 1 to recipient 1 - sender gets graylisted - sender tries to send message 2 to recipient 1 - sender gets graylisted - sender retries message 1 after graylist timeout - sender gets permitted to transfer message content - sender retries message 2 - sender gets permitted to transfer message content immediately - sender tries to send message 3 to recipient 1 within graylist expiry timeout - sender gets permitted to transfer message content immediately First of all Message-ID values will with current graylisting implementation only be logged after successfully passing graylisting. So to change this message needs to be transfered completely before graylisting steps in. I for myself wouldn't want it to happen, because I don't want to pay with my systems resources and traffic for messages I don't want to receive :-) Second for message 3 there's no graylisting delay log, because sender and recipient tuple is already validated. So, even if also logged for delayed messages, which would require changes in graylisting behavior, for this message there would only be one log entry and nothing to match with for counting delayed vs. allowed :-) As always, thanks to Sam for his great work on spamdyke. Seconded :-) -- Regards, Peter ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
