Re: [spamdyke-users] getprotobyname() -

[David Bo Jensen]

Problem solved.
ulimit in my qmail script was simply too low
___
spamdyke-users mailing list
spamdyke-users@spamdyke.org
http://www.spamdyke.org/mailman/listinfo/spamdyke-users

Re: [spamdyke-users] Enhancement: log TLS indicator

[Sam Clippinger]

I agree a log indicator would be good (and easy to add).  spamdyke 
doesn't add any headers presently, though I've gotten several requests 
along those lines.

I haven't looked very hard at DKIM (yet) so I'm not entirely sure how it 
works, but I thought it was an authentication system for the sending 
mail server, not the email author or message content.  In any case, most 
signature systems for email don't use the headers for calculating 
checksums.  If they did, there'd be problems all over with standard 
Received headers, SpamAssassin headers, etc.

-- Sam Clippinger

Eric Shubert wrote:
 Eric Shubert wrote:
   
 Eric Shubert wrote:
 
 The todo file has a handfull of nice logging enhancements. Here's another.

 It'd be nice to have some indicator in the log of whether TLS was used 
 on each session or not. This would allow easy verification that TLS is 
 working on each message coming in.

 Thanks Sam.
   
 There's another aspect to this that Aleksander on the QMT list came 
 across. He noticed that when spamdyke's doing the TLS encryption, 
 there's no longer any indication in the message header that the message 
 was encrypted as it was received. When qmail (patched with TLS) accepts 
 a message using TLS, it notes that the message was received with 
 encryption. Since spamdyke is passing the message in clear text to 
 qmail, qmail no longer notes that TLS was used, even though spamdyke is 
 dutifully decoding the encrypted session.

 The bottom line to this is that there's no practical way to audit that 
 TLS is being used, or was used on a given message. I think this is a 
 significant shortfall, while more so in some environments than others.

 Would it be possible for spamdyke to add a Received-spamdyke header of 
 some sort that would indicate whether or not TLS was used? I imagine 
 that other relevant information about spamdyke could be included, but I 
 think Sam would have better ideas about this than I do.

 Thanks again Sam.

 

 Alexsander just pointed out that it probably won't be possible for 
 spamdyke to add a received header to the message, as this would break 
 DKIM. Looks like the only way to preserve the qmail encryption message 
 in the headers would be to pass the message on to qmail using TLS if 
 it's available (and only when spamdyke is using TLS with the sender of 
 course). I'm not sure if the additional overhead would be worth it or 
 not, but I expect not. It sure be nice though if the security of a 
 message could be validated by examining its headers.

 Having an indication in the log is looking to be more important in light 
 of this.

 Any ideas, Sam?
   
___
spamdyke-users mailing list
spamdyke-users@spamdyke.org
http://www.spamdyke.org/mailman/listinfo/spamdyke-users

Re: [spamdyke-users] make use of already positively graylisted senders

[Sam Clippinger]

Actually, this isn't a bad idea, it just won't work with spamdyke.  As I 
understand it, you want to use a successful graylist entry as evidence 
that the sending server is legitimate.  For example, once a message from 
gmail.com has passed the graylist, there's no point in graylisting all 
of its future messages because obviously the server will retry and 
eventually pass the filter.  Always enforcing the graylist seems like a 
waste of time and resources.

Unfortunately, when spamdyke creates a graylist entry, it only looks at 
the sender's and recipient's email addresses.  It doesn't look at the 
sending server's name or IP address.  So, if a message is received from 
an aol.com mail server, from an aol.com email address, it will pass the 
graylist filter because AOL uses real mail servers that retry 
deliveries.  However, if a spambot on a cable modem sends a message from 
a different aol.com address, the graylist filter could stop it because 
the spambot won't retry the delivery.  Just because both messages appear 
to come from aol.com addresses is irrelevant.  The sending server is 
what's important.

Even if spamdyke checked the sending server's IP address, you still want 
graylisting to always take place.  Imagine a scenario where a business 
hosts their own email in-house, using an Exchange server behind a NAT 
firewall.  All connections to spamdyke, whether they are from the 
Exchange server or the virus-infected Windows workstations, will appear 
to come from the same IP address.  The Exchange server will always pass 
the graylist filter but the infected PCs won't.

A little background: spamdyke doesn't consider the sending server's IP 
address when graylisting because large mail hosts (e.g. GMail, AOL, 
Yahoo!) use multiple outbound SMTP servers.  When a user sends a 
message, server A will attempt to deliver it, get graylisted and put the 
message back in the queue.  Later, server B might retry the delivery and 
get graylisted again.  In that situation, a message could easily bounce 
before it passed graylisting.

-- Sam Clippinger

mrxxxmryyy wrote:
 Hello,

   
 You must be either hosting couple of user accounts only or
 you had never spent a second reading your servers' logs.
 

 I'm not sure if it matters as far as my idea is concerned.

   
 Exampke below, just randomly-picked machine I have, todays log
 (and I see thousands of this shit daily; replaced target,
 legitimate domain with @x, but it does not really matter):
 

 I'm afraid it has nothing to do with the idea. To make it simple
 again: John and George have email accounts on my server. Jane (who
 has an email account on some server, not mine) sends an email to John.
 Since it is a legitimate email it is passed after graylisting.

 OK, and now the clue. There's next email from Jane. It is to George,
 and this is _the_only_ difference from email number 1 to John (so it
 would be passed if it was to John, however it is to George so it isn't
 passed because it's graylisted first).

 So, if email no. 1 has been passed and now Spamdyke remembers that
 every email from Jane (sender, IP, etc.) to John should be accepted
 for given time without graylisting it, why not make use of this and not
 to apply this rule for mail from Jane to George?

   
___
spamdyke-users mailing list
spamdyke-users@spamdyke.org
http://www.spamdyke.org/mailman/listinfo/spamdyke-users