hi -- this stuff is generally recorded in the Received header, and SA will act on it if it's there. that's the place to do it...
--j. On Fri, May 15, 2009 at 09:42, Mike Cardwell <spamassassin-us...@lists.grepular.com> wrote: > One of SpamAssassins weaknesses is that it only has access to the message > body of the email. It can't create rules to detect certain behaviours of the > connecting host during delivery. > > For example, during SMTP. If the connecting client sends: > > MAIL FROM: <u...@example.com> > > Instead of: > > MAIL FROM:<u...@example.com> > > That is a *high* indicator that the email is going to be spam. I haven't > found a real mail server that adds that whitespace it's self when sending > mail as it's not allowed by the RFCs, however many (all?) mail servers seem > to accept it for incoming connections. > > I configured Exim quite a while ago to add a header to the message when this > happens, and then configured SpamAssassin to check for that header, but it > would be better if SpamAssassin had some sort of interface which could be > plugged in to from mail servers whilst SMTP communication is taking place... > > Another example. From what I've seen, hosts in botnets don't take advantage > of the SIZE extension in SMTP. So if the client sends: > > MAIL FROM:<u...@example.com> SIZE=12345 > > Then that's an indicator that the connecting host isn't a zombie. I haven't > tried it out yet, but I'm guessing you'd find a similar result for > connections that use the 8BITMIME extension to ESMTP. > > Another indicator that the connecting host isn't a zombie, is if it uses > STARTTLS. > > This is all useful information that spamassassin is missing out on. I'm sure > there are many more signatures that spamassassin could take advantage of if > it had such an interface... > > -- > Mike Cardwell > (https://secure.grepular.com/) (http://perlcv.com/) > >
