Re: Spam from RCVD_IN_IADB (ISIPP/Surety Mail)
On 02/17/2014 02:35 PM, Greg Troxel wrote: > I have had a number of experiences complaining about spam from > whitelisted hosts, and (with the exception of hostkarma, which is not > in the default ruleset) found many of my experiences to be > unsatisfactory, to the point that they were escalated to publically > discussing the issue. Regarding this problem generally, yeah its an issue, especially with one whitelist in particular, that is NOT the ISIPP/IADB. Regarding ISIPP/IADB in particular, I'd be hard-pressed to call it a whitelist. IMHO it would be more accurate to call it a combined whitelist and blacklist... or a reputation list, or something. For instance.. Per http://www.isipp.com/email-accreditation/list-of-codes/ A response of 127.3.100.100 means "The only email which comes from this IP address is mailing list email, and that mailing list email is entirely confirmed (double) opt-in" I'd treat that response as a whitelisting. On the other hand, a response of 127.3.100.1 means "Scrapes addresses, pure opt-out only" I'd tend to treat such a response as a blacklisting. My understanding (which could be mistaken, and hopefully someone more knowledgeable will chime in if I'm wrong) is that listees pay to be listed, but they don't necessarily get to decide under what category. Also, IIRC, by default only certain responses are treated by spamassassin with negative points, certain other responses are treated with adding postive pointage. Now, with regards to the OP's spam sample, the IADB related tests that fired were: RCVD_IN_IADB_DK In other words, sender uses DK or DKIM. Looks accurate to me. RCVD_IN_IADB_DOPTIN_LT50 In other words, sender uses confirmed opt-in *LESS THAN HALF THE TIME* Considering that the sender spammed the OP, this is probably accurate as well. RCVD_IN_IADB_LISTED Ie, the sender is listed. Accurate by its very nature. RCVD_IN_IADB_RDNS Proper RDNS is set up. Again, looks to be accurate. RCVD_IN_IADB_SENDERID Uses sender ID. I didn't check, but wouldn't be surprised if this were true. RCVD_IN_IADB_SPF Since SPF_PASS also fired, this is probably accurate as well. RCVD_IN_IADB_VOUCHED AFAIK simply means that sender has been listed > 6 months, and its practices are consistent with how its listed. Probably accurate. Now, if they IP that sent the OP's spample were listed as using COI all the time, then it would make sense to complain to SuretyMail about it so the listing could be changed - but that is not how it is listed. So, regarding ISIPP/IADB, I don't think the DNSxL operator is to blame for any FNs, nor doing anything improper. Rather, I'd say maybe the scoring defaults should be tweaked a little bit. -- Joe Sniderman
Re: How to get removed from spamcop?
On 10/29/2013 12:19 PM, Benny Pedersen wrote: > Marc Perkel skrev den 2013-10-28 22:06: >> Just wondering if any real people are there or if it's totally >> automated. They have several of our IP addresses listed and delisting >> doesn't seem to work. We're a spam filtering company (Junk Email >> Filter) and if we fail to block a spam it can appear we are the >> source. > > and ?, do you see your own logs who use spamcop.com as rbl ? > > http://www.mywot.com/en/scorecard/spamcop.com > > users of wot dont trust them o rly: https://www.mywot.com/en/scorecard/spamcop.net -- Joe Sniderman
Re: How to get removed from spamcop?
On 10/28/2013 05:06 PM, Marc Perkel wrote: > Just wondering if any real people are there or if it's totally > automated. They have real people there. > They have several of our IP addresses listed Hmmm > and delisting doesn't seem to work. Strange > We're a spam filtering company (Junk Email Filter) and if we fail to > block a spam it can appear we are the source. Are you positive that this is the cause of the listing, or just speculating. Also, do you only provide inbound filtering to your customers, or outbound too? If you only provide inbound, and your customers are rejecting mails you've already accepted on their behalf (sounds like this may be the case) do you then generate a bounce? Could some of those bounces be what caused the listing in the first place? Just throwing some ideas out there.. -- Joe Sniderman
Re: SUBJ_ALL_CAPS
On 08/20/2013 12:35 PM, Andrew Talbot wrote: > Hey all - > > > > Does anybody know how long the string needs to be to trigger SUBJ_ALL_CAPS? > I know it has to be multi-word and over a certain length. Was wondering the > specific length. Thanks in advance J IDK, but on an interesting side note, it appears your message did not trigger the rule... Subject: SUBJ_ALL_CAPS X-ASF-Spam-Status: No, hits=1.5 required=10.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS Maybe a string of multiple words separated by underscores is not considered multiword... -- Joe Sniderman
Re: Privacy Concerns and Implementing Corrective Proceedures To Combat Information Harvesting
On 09/06/2012 12:40 AM, NMTUser X wrote: > Would it be possible to send mail to myself encrypted in pgp/gpg, use a > token at the beginning of the email with the correct email address (which > is on the local network) have procmail or spamassassin parse all incoming > messages, strip the headers, decrypt the message, and reinsert it into the > mail spool to be forwarded to the correct person? Possible? Sure. Advisable? Maybe or maybe not. Not sure I see what you are hoping to accomplish by doing so though.. If you want to keep the connection between your MUA and your MTA encrypted, use TLS. If you don't trust CAs, create your own private CA. Of course, none of this prevents spammers/list-brokers from obtaining your address by means of dictionary attacks. Of course nor will spamassassin (nor any filtering solution.) > If so where do I begin to look? > Could (gpgzip) attachments be preserved? Probably. > This would allow me to continue to use gpg I could ditch google and use ANY > mail forwarding agent - even hushmail - and I could keep my professional > life intact. I'll take your word for it. -- Joe Sniderman
Re: Spamassassin detect my mails as spam
On 02/24/2012 06:23 AM, Michelle Konzack wrote: > In relation to the previous poster with the fetchmail problem (the > receiver should hide fetchmail received header by adding "set invisible" > in the "global" section) I have the probvlem, that receiving MTAs runing > spamassassin consider my mails as spam du to the received headers... > > Scenario: > > 1) My enterprise (exactly 5) has several internal subnets and each > one is seperately protected by firewalls. > > 2) It is NOT possibel, to send mails to the internet trough 25/587 > > 3) All mail must go via the INTRANET server which use a public relay > > So, now if I send a mail it looks like > > a) Workstation work1.intranet1.tamay-dogan.net (192.168.0.13) > b) Intranet Server samba.intranet1.tamay-dogan.net (192.168.0.12) > > now using auth-smtp (my fixed IP @office is 85.182.220.41 but can not > have rDNS) > > c) Public mail server mail.tamay-dogan.net (78.47.247.21) > d) Receiving mail server So far, so good. > If now d) is runing spamassassin, thaen my messages are to 90% rejected. Strange. What tests are firing? > Is there a was to solv this? Probably. First step is to find out what is causing it. > Note: I see, not all spamassassin setups rejecting my mails including >my own one if it receive mails from others and same setup. I'm not following.. Are you saying your SA setup is one of the setups that does reject your mails, or are you saying your SA setup is one of the setups that does not reject your mails? FWIW, it looks as though the SA instance that apache is using in front of the mailing list is *not* tagging your posts as spam: X-ASF-Spam-Status: No, hits=-0.7 required=10.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS HTH -- Joe Sniderman
Re: Getting high spam score for email server hosted on AWS instance
On 02/10/2012 02:16 AM, Sharma, Ashish wrote: > The cluster with which I am facing problem is different one. > > The node for which I am getting high spam score has the following details: > > cloudemail5.cpgtest.ostinet.net (184.72.247.145) No other Received lines? -- Joe Sniderman
Re: Getting high spam score for email server hosted on AWS instance
On 02/08/2012 12:22 PM, Joe Sniderman typed hurriedly: > IOW, 196.254.0.0/16 no longer matches as of 3.3 Well, I meant to type 169.254.0.0/16... but then.. obvious typo is obvious. -- Joe Sniderman
Re: Getting high spam score for email server hosted on AWS instance
On 02/08/2012 08:57 AM, Michael Scheidell wrote: > On 2/8/12 6:41 AM, Sharma, Ashish wrote: >> Hi, >> >> I have a mail server setup on an AWS instance. >> >> When I am sending mails via this setup to a test spamassassin setup >> that acts as an email receiver server, I am getting high spam scores >> as follows: >> >> [FROM_LOCAL_HEX=0.331, HTML_IMAGE_ONLY_24=1.282, HTML_MESSAGE=0.001, >> RCVD_ILLEGAL_IP=3.399, T_REMOTE_IMAGE=0.01, T_RP_MATCHES_RCVD=-0.01] >> autolearn=no >> >> >> As can be seen, the highest contributor is "RCVD_ILLEGAL_IP=3.399" > no, since the ip address in question is, by definition, an unroutable > ip, and should never be seen in a received list > (I am just guessing: > > Received: from G9W0725.americas.hpqcorp.net ([169.254.8.28]) by That should not be a problem in and of itself... 169.254.0.0/16 is intended for link-local.. (see RFCs 5735 and 3330) It might or might not be less than ideal to use addresses in 169.254.0.0/16 for the communication between one machine and a smarthost on a LAN, but far from illegal. 169.254.0.0/16 is also notably *not* mentioned in the wiki for RCVD_ILLEGAL_IP: http://wiki.apache.org/spamassassin/Rules/RCVD_ILLEGAL_IP All that said, RCVD_ILLEGAL_IP _used to_ hit on IPs 169.254.0.0/16, but AFAIK that changed with 3.3. See also: https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6460 And: http://svn.apache.org/viewvc/spamassassin/branches/3.3/rules/20_head_tests.cf?view=markup#l423 # must keep it in sync with http://www.iana.org/assignments/ipv4-address-space/ header RCVD_ILLEGAL_IP X-Spam-Relays-Untrusted =~ / (?:by|ip)=(?=\d+\.\d+\.\d+\.\d+ )(?:0|2(?:2[4-9]|[3-5]\d)|192\.0\.2|198\.51\.100|203\.0\.113)\./ describe RCVD_ILLEGAL_IP Received: contains illegal IP address IOW, 196.254.0.0/16 no longer matches as of 3.3 > You have a microsoft cluster, where microsoft thought it would be a good > idea to use 169.254.0.0/16 ip addresses?) Its really not that horrible an idea.. > Bring this up with microsoft, have them 'fix' this. Or better yet, the OP should bring it up with whoever is running the test spamassassin instance and get them to upgrade it. -- Joe Sniderman
Re: Detecting serious domains
On 11/17/2011 10:27 AM, Marc Perkel wrote: > I'm exploring a variety of ideas to determine the difference between > "serious" domains down to throw away domains used by spammers. The ideas > I'm presenting here are not complete but are just a conversation starter. I'd think domain age would be biggest indicator of *not* being a throw-away domain. IIRC you already track that in your own dns lists.. > for example, if the sending domain has no MX records of its own it is > more likely spam that if there are 3 or more MX records that resolve to > multiple IPs over more than one network. Generally spam only domains are > minimally configured, and highly configured domains are not spam only. I > also think that NS records might indicate that a domain is serious or not. Maybe. Keep in mind that a throw-away domain might be purchased through a registrar that provides email hosting, and might appear to be nicely configured. Perhaps in combination with age, this could be a semi-useful indicator.. ie, new domain, only one (implicit) MX, decent chance of being a throw away. old domain, probably not a throwaway, new domain, nicely configured is hard to tell though... There also are free email hosting options that involve multiple MXs.. Put yourself in spammy's shoes for a moment... if you had a throwaway domain would you host the incoming email on your own servers, or on gmail apps? I'd choose gmail in heartbeat. Then again plenty of legit domains use gmail too, so in and of itself its not a sign of seriousness nor of lack thereof. Regarding NS records, yeah there are some nameservers that seem to only host bad domains, others that seem to only (or mostly) host good domains, and then a whole bunch that host all kinds of domains. Nameserver reputation might be a good track to follow IMHO. If you're trying to predict how serious a newly registered domain is, I'd look at the nameservers, and the whois. Private registration, cheap registrar, cheap dns, brand new domain, probably bad news until more info is available Proper whois info, expensive registrar, expensive dns and/or dns with a good reputation, brand new domain, far less suspicious. Proper whois info, cheap registrar, expensive dns and/or dns with a good a reputation, brand new domain, somewhere in the middle. I'm just thinking "outloud" here, does this sound sensible to you? > I think the serious scale could be a useful factor in SA. It doesn't > determine if it's spam or ham in itself. Yahoo is a serious domain and > there's lost of spam. Serious domains should not be blacklisted for > example. We could also look for consistency. Bad RDNS from a serious > domain might be a spam indicator. > > There might be other methods of detecting serious domains. If they are > using expensive services. Spammers would not have their dns hosted with > Ultra DNS, or use the expensive registrars, or other services that are > expensive. Well, spammers might well use UltraDNS and/or expensive registrars, but probably would only do so for their domains which they intend on keeping long term, rather than ones they intend to throw away. > Also - thinking we should slowly mine the whois database and provide > some sort of DNS based lookup of whois information to be able to > determine the registrar of a domain, the domain age, or other info that > would be useful in determining that the domain is serious or not. That is nothing new. Spam eating monkey AFAIK has some zones which tell about privitized whois, age of registration, etc. You also have a zone if I'm not mistaken that approximates how long ago a domain was first seen (by your users) in email. Some of the SORBS zones can also be used in tandem with each other to extrapolate similar info. Senderbase also keeps tabs on history of domains as well as IPs.. Question becomes how to use the data in a way to approximate the "seriousness" of the domain, and then how to use the approximated domain "seriousness" to improve filtering. Two separate questions if you ask me. > Who thinks I'm onto something? I think you *might* be on to something, or might not. Here's another thought off the top of my head: looking at nameservers and calculating average age of domains hosted on the nameservers, as well as the average length of time that the domains hosted on the nameservers have been on those specific nameservers... -- Joe Sniderman
Re: Rule to match X-Spam-Flag
On 06/09/2011 11:06 AM, Mark Martinec wrote: > Benny, > >>> As a workaround, you may add some header rewrite rule to your MTA >>> which could rewrite a X-Spam-Flag to something else, like >>> X-X-Spam-Flag. >> >> will not give invalid dkim ? > > No, unless the X-Spam-Flag were signed, which is unlikely. Even so, one could add (instead of rewriting) an X-X-Spam-Flag or X-Original-Spam-Flag or whatever, while leaving the X-Spam-Flag intact and in place. That way, even if for some reason the X-Spam-Flag were signed, DKIM would be unaffected. Or one could perform DKIM verification first [1], then re-write the header, then pass the mail to spamassassin. [1] using opendkim or dkim-filter or whatever. not sure if spamassassin will use that result or perform its own verification, but either way if the goal is to tag, so what if spamassassin also sees a DKIM failure. if humans want to know that it passed for whatever reason, the authentication-results header would still be there. -- Joe Sniderman
Re: Yahoo sent 5.5x as much spam as any other legit provider in April
On 05/11/2011 04:35 PM, Michael Scheidell wrote: > if someone sends an email to 175 people, once they hit 'x' number in the > first email attempt, we send '4xx too many emails' > ie: > ehlo *.yahoo.com > mail from: > rcpt to: > 250 ok > rcpt to: > 250 ok > [skip to 100]. > rcpt to: > 4xx too many We do something similar, except that the maximum number of recipients per envelope we set at 1. The second and all subsequent get a 4yz error during RCPT. We perform this after greylisting, ie: ... RCPT TO: 451 4.7.1 Greylisting in action RCPT TO: 451 4.7.1 Greylisting in action ..some time later... RCPT TO: 250 ok RCPT TO: 451 4.7.1 One at a time please DATA ..after another retry.. RCPT TO: 250 ok DATA Rationale being that content filtering during DATA can be customized on a per recipient basis, without having to generate bounces after the fact nor resorting to dropping emails silently. > RFC'S seem to indicate that they should send a data command next and > send the email to be delivered to the first 99, then try the next 51 on > the next highest mx. Or in our case, the first one, and retry for the next 149, get one more out, retry for the next 148, and so on. We do greylist, and Yahoo gets a rather long default greylisting and very short AWL. > doesn't happen on yahoo.com > they drop the connection, and try again at next highest mx, then on mx4, > bounce the email back to sender with the last mx's ip in the error > message and the 4xx too many Interesting. My experience has been that Yahoo does retry at the same MX but will not go to the next MX in response to 4yx errors. (OTOH if the connection times out they do go on the next MX) -- Joe Sniderman
Re: Yahoo sent 5.5x as much spam as any other legit provider in April
On 05/11/2011 04:19 PM, dar...@chaosreigns.com wrote: > I bet it's largely related to the fact that yahoo is apparently the only > freemail provider that doesn't require you to have a previously existing > email address. Yahoo does not require an existing address. Hotmail/MSN/Live does not require an existing address. AOL/AIM does not require an existing address. Gmail does not require an existing address. [1][2] Mail.com does not require an existing address. ... It seems GMX.com *does* require an existing address. This appears to be the exception rather than the rule. > I also suspect that, for this reason, google.com would send less spam > if they didn't allow yahoo addresses as the pre-existing address. *If* Gmail were to require an existing address, prohibiting Yahoo addresses *might* make sense. [1] This seems to depend on the IP address used to sign up for the google account. When signing up through a TOR exit node (at least at the time that I tried it, which was > 1yr ago) Gmail asked for either a cellphone number for text confirmation, or an existing email address. Yahoo did not differentiate between TOR exit nodes and non-TOR IPs. [2] Google apps accounts however do seem to require a preexisting email address, however gmail addresses are accepted for that purpose. -- Joe Sniderman
Re: whitelist ip in trusted network
On 05/06/2011 08:38 PM, Rajesh M wrote: > hi > > i wish to whitelist a few client's server's static ip in the spamassasin > trusted network > > i am entering a line like this in local.cf file. > > trusted_networks xxx.yyy.zzz.ppp > > if i do this then the email from this server ip should be given a negative > score but it does not seem to work No, it effects how SpamAssassin regards Received lines added by those IPs. (ie, it causes SpamAssassin to trust that the Received line is not forged) You also might want to have a peek at: http://wiki.apache.org/spamassassin/TrustedRelays and http://wiki.apache.org/spamassassin/TrustPath > spamassassin does not work for any ip that i put here, even those ips of does not work? > my other servers are not trusted. > It seems that spamassassin is simply not > even looking at the trusted network ips ie it is disabled due to some > reason Or it could be that you are expecting trusted networks to act as a whitelist, which is not its function. > could you please help. Perhaps easiest way: make a local dns whitelist of IPs to which you feel your setup should apply a negative score, and then add some nice net rules to go along with it. Also, you might want to have a look at: whitelist_from_rcvd , which is documented here: http://spamassassin.apache.org/full/3.1.x/doc/Mail_SpamAssassin_Conf.html#whitelist_and_blacklist_options Short version: Say your client is example.com and uses mail.example.com, you could do: whitelist_from_rcvd *@example.com mail.example.com to give negative points to mail from example.com that you receive from mail.example.com. HTH. -- Joe Sniderman
Re: spamass-milter - mailing list
On 01/25/2011 02:29 PM, JKL wrote: > Hi there, > > Is there a mailing list specifically for problems arising from > spamass-milter? There is a spamass-milter mailing list, yes: http://lists.nongnu.org/mailman/listinfo/spamass-milt-list HTH -- Joe Sniderman
