Re: whitelist_from in SQL not applied?
Philippe Ratté skrev den 2013-02-13 23:05: dbg: spf: def_spf_whitelist_from: already checked spf and didn't get pass, skipping whitelist check why does it not get pass when spf is okay ? http://dmarcian.com/spf-survey/hotmail.com | 3485 | %domain.ca | whitelist_from | u...@hotmail.com | dont use whitelist_from, with that setting anyone can use that email as sender to get whitelisted, this is okay if you do spf testing in mta only, so spamassassin follow it as an ok, but not if you are not testing spf in mta have you configured Mail::SPF to reuse mta spf (recieved-spf header) ?
TBIRD_SPOOF
Hi list,
Is it just me or is TBIRD_SPOOF hitting pretty much all initial email
sent by Thunderbird, not via a ML etc?
$ grep TBIRD_SPOOF *.cf
72_active.cf:##{ TBIRD_SPOOF
72_active.cf:meta TBIRD_SPOOF __MUA_TBIRD
!__HAS_IN_REPLY_TO !__HAS_X_REF !__THREADED !__VIA_ML
!__NOT_SPOOFED !__HAS_SENDER !__HAS_ERRORS_TO
!__HAS_X_BEEN_THERE !__RP_MATCHES_RCVD !ALL_TRUSTED
!__TO_EQ_FROM_DOM
72_active.cf:describe TBIRD_SPOOF Claims Thunderbird
mail client but looks suspicious
72_active.cf:#score TBIRD_SPOOF 3.00 # limit
72_active.cf:##} TBIRD_SPOOF
72_scores.cf:score TBIRD_SPOOF 3.000 2.999
3.000 2.999
If I send myself a simple test message, routed externally so as not to
hit ALL_TRUSTED, I get a hit on this rule. Replies etc are OK but the
initial email hits TBIRD_SPOOF and scores 3pts so it's that initial
first email in a tread that gets clobbered.
Any suggestions how to fix this?
Re: Telling BAYES not to learn?
Martin Gregorie skrev den 2013-02-11 16:41: Maybe there's a case for classifying mail as ham/spam by reading the raw mail instead of looking at it with an MUA and being shown the HTML part? why is it needed ?, if mua clients dont trust html, then use text mode mua, problem is gone well it is possible, but create an sed -e /html/text/ is a bit overkill, and this stops relearning into bayes, best option is to ask for abuse support in mail clients to not trust any html collers, or redefine them so its basic custom designed to not being what html was ment them to be displayed as :)
Re: X-Relay-Countries
On 12/02/13 20:33, Daniel McDonald wrote: On 2/12/13 1:15 PM, David F. Skolld...@roaringpenguin.com wrote: PS: Beware of penalizing other countries too much. My mail originates from Canada and the PostgreSQL mailing list is (or used to be?) hosted in Panama. Furthermore, by far the lion's share of spam originates from the US. Yes, of course. But some mail just isn't likely to originate overseas. For example, we have been getting a lot of phishes pretending to be FedEX non-delivery notices. FedEX is based in the US, so if I see FedEX and RELAY_NOT_US, and a couple of other spam signs, I can more safely conclude it is spam Nice idea, but why not just use SPF for fedex.com as they bother to publish an SPF record? Surely that has to be a far more reliable indicator it wasn't sent from fedex? $ dig txt fedex.com ;; ANSWER SECTION: fedex.com. 10578 IN TXT v=spf1 redirect=_spf.infosec.fedex.com They might sign their mail too, but as I don't have any legitimate fedex mails to hand, I can't confirm that.
Re: X-Relay-Countries
Steve Freegard skrev den 2013-02-12 21:19:
header RELAY_NOT_US X-Relay-Countries =~ /\b(?!US)[A-Z]{2}\b/
and what date is the database from ?, ip2cc ipv4-addr, to show it when
its build, to update it either use the new relay_country plugin or
update ip2cc database, if its over 6 mounts its time for a change
Re: TBIRD_SPOOF
On 14/02/13 12:04, Ned Slider wrote:
Hi list,
Is it just me or is TBIRD_SPOOF hitting pretty much all initial email
sent by Thunderbird, not via a ML etc?
$ grep TBIRD_SPOOF *.cf
72_active.cf:##{ TBIRD_SPOOF
72_active.cf:meta TBIRD_SPOOF __MUA_TBIRD !__HAS_IN_REPLY_TO
!__HAS_X_REF !__THREADED !__VIA_ML !__NOT_SPOOFED
!__HAS_SENDER !__HAS_ERRORS_TO !__HAS_X_BEEN_THERE
!__RP_MATCHES_RCVD !ALL_TRUSTED !__TO_EQ_FROM_DOM
72_active.cf:describe TBIRD_SPOOF Claims Thunderbird mail client but
looks suspicious
72_active.cf:#score TBIRD_SPOOF 3.00 # limit
72_active.cf:##} TBIRD_SPOOF
72_scores.cf:score TBIRD_SPOOF 3.000 2.999 3.000 2.999
If I send myself a simple test message, routed externally so as not to
hit ALL_TRUSTED, I get a hit on this rule. Replies etc are OK but the
initial email hits TBIRD_SPOOF and scores 3pts so it's that initial
first email in a tread that gets clobbered.
Any suggestions how to fix this?
Replying to myself,
I just updated my rules with sa-learn as I hadn't updated for a few
days, and it seems this rule has disappeared. Looks like it was only out
in the wild for a short time.
Thanks to those who replied off list.
Problem solved!
Re: Telling BAYES not to learn?
On Thu, 2013-02-14 at 13:18 +0100, Benny Pedersen wrote: Martin Gregorie skrev den 2013-02-11 16:41: Maybe there's a case for classifying mail as ham/spam by reading the raw mail instead of looking at it with an MUA and being shown the HTML part? why is it needed ?, if mua clients dont trust html, then use text mode mua, problem is gone Exactly. It seems to me that a lot of people, possibly OP included, may not realise that most graphical MUAs default to showing the HTML part so the ham/spam reviewer may not realise they are being shown some white-on-white text and/or that the plain text part is often quite different from the HTML part. I don't know any MUA that will show both plaintext and HTML, which is why I suggested that the ham/spam classification reviewer do it with less rather than an MUA. Martin
Re: X-Relay-Countries
On 2/14/13 6:21 AM, Ned Slider n...@unixmail.co.uk wrote: On 12/02/13 20:33, Daniel McDonald wrote: On 2/12/13 1:15 PM, David F. Skolld...@roaringpenguin.com wrote: PS: Beware of penalizing other countries too much. My mail originates from Canada and the PostgreSQL mailing list is (or used to be?) hosted in Panama. Furthermore, by far the lion's share of spam originates from the US. Yes, of course. But some mail just isn't likely to originate overseas. For example, we have been getting a lot of phishes pretending to be FedEX non-delivery notices. FedEX is based in the US, so if I see FedEX and RELAY_NOT_US, and a couple of other spam signs, I can more safely conclude it is spam Nice idea, but why not just use SPF for fedex.com as they bother to publish an SPF record? Surely that has to be a far more reliable indicator it wasn't sent from fedex? $ dig txt fedex.com ;; ANSWER SECTION: fedex.com. 10578 IN TXT v=spf1 redirect=_spf.infosec.fedex.com They might sign their mail too, but as I don't have any legitimate fedex mails to hand, I can't confirm that. We get plenty of messages from suppliers stating that they have made a shipment, and the fedex tracking number is foo. But lately we've been getting a lot of phishes where the link for the fedex tracking number actually points to malware, and most of these are using cracked accounts and are being generated on botnets, so I'm looking for a fedex tracking link that didn't originate locally. -- Daniel J McDonald, CCIE # 2495, CISSP # 78281
hinet.net?
Is anyone else being plagued by unreadable nonsense from hinet.net? It originates from China, it seems. I've just had to tell procmail to send it all to the bit bucket. Just curious. Is hinet.net a known problem?
RE: whitelist_from in SQL not applied?
The mail came from 65.54.190.123 and it passes SPF dont use whitelist_from, with that setting anyone can use that email as sender to get whitelisted, this is okay if you do spf testing in mta only, so spamassassin follow it as an ok, but not if you are not testing spf in mta What should I use, then? SPF is not checked at mta have you configured Mail::SPF to reuse mta spf (recieved-spf header) ? No
Re: SA failed: Can't locate object method get_tag via package Mail::SpamAssassin::PerMsgStatus at (eval 86) line 425
On 2/13/2013 11:03 PM, Anirudha Patil wrote: On Tue, Feb 12, 2013 at 6:16 PM, Mark Martinec mark.martinec...@ijs.si mailto:mark.martinec...@ijs.si wrote: Anirudha, I have a stable running setup of postfix after-queue using amavis-new [currently using for content inspection and antivirus only] and would like to use this for additional spam protection. As i understand from the above comments to my query, i dont need to run the 'spamd' as separate process, but would invoke the spamprotection via amavis-new [via spamassasin perl moduled]. Exactly. I would continue to install the latest version of spamassasin with existing amavis-new and check if the same error is encountered. Right. Thank you Mark and Bailey, I have upgraded the spamassasin to 3.3.2, now i dont see the initial error message and can see that amavis is invoking the multiple rulesets of SA and also the corresponding scores are set for emails. Does SA increases the load on the system ? Are they any tweaking guides to enable only specific rules in SA and not all? The main thing to watch for with SA is memory usage. Each Amavis process will load up all of the SA rules, so they can use a fair chunk of RAM. Make sure to tweak the max number of processes in the Amavis config so that you don't go into swap when the system gets busy. SA is already tuned as much as possible for general use. Unless you have specific problems, it is not usually a good idea to disable any of the default rules. Most of the tweaks you will find for SA involve loading extra rules. This causes SA to use more resources, but it can increase the accuracy. http://wiki.apache.org/spamassassin/ImproveAccuracy -- Bowie
Re: hinet.net?
Am 14.02.2013 15:24, schrieb Walter Hurry: Is anyone else being plagued by unreadable nonsense from hinet.net? It originates from China, it seems. I've just had to tell procmail to send it all to the bit bucket. Just curious. Is hinet.net a known problem? yes, hinet is a problem since ever , use ie spamhaus rbl at smtp level to block them Best Regards MfG Robert Schetterer -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Joerg Heidrich
Re: X-Relay-Countries
On Thu, 14 Feb 2013 12:21:33 + Ned Slider n...@unixmail.co.uk wrote: Nice idea, but why not just use SPF for fedex.com as they bother to publish an SPF record? Surely that has to be a far more reliable indicator it wasn't sent from fedex? That works if the envelope sender is someth...@fedex.com, but if the header sender is from fedex.com and the envelope sender is spam...@passes-spf.org then SPF is useless. I experimented with applying SPF tests to the header From: (which is against the spec), but it had way too many false-positives. They might sign their mail too, but as I don't have any legitimate fedex mails to hand, I can't confirm that. I don't believe they use DKIM. Regards, David.
Re: TBIRD_SPOOF
On Thu, 14 Feb 2013, Ned Slider wrote: Hi list, Is it just me or is TBIRD_SPOOF hitting pretty much all initial email sent by Thunderbird, not via a ML etc? That was an experimental rule that hasn't panned out and has been removed. It should go away with the next update. -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- No representation without taxation! --- 8 days until George Washington's 281st Birthday
Re: hinet.net?
On 14/02/13 14:34, Robert Schetterer wrote: Am 14.02.2013 15:24, schrieb Walter Hurry: Is anyone else being plagued by unreadable nonsense from hinet.net? It originates from China, it seems. I've just had to tell procmail to send it all to the bit bucket. Just curious. Is hinet.net a known problem? yes, hinet is a problem since ever , use ie spamhaus rbl at smtp level to block them Best Regards MfG Robert Schetterer +1 - just block them at the MTA, either with Spamhaus or a local IP blocklist. Here's the list I have for HINET - might not be complete. $ cat /etc/postfix/client.cidr | grep -i hinet 59.112.0.0/14 REJECT # Hinet.net blocked 59.116.0.0/15 REJECT # Hinet.net blocked 59.120.0.0/15 REJECT # Hinet.net blocked 61.216.0.0/13 REJECT # Hinet.net blocked 61.224.0.0/13 REJECT # Hinet.net blocked 111.240.0.0/12 REJECT # Hinet.net blocked 114.24.0.0/14 REJECT # Hinet.net blocked 114.32.0.0/12 REJECT # Hinet.net blocked 118.160.0.0/15 REJECT # Hinet.net blocked 118.164.0.0/14 REJECT # Hinet.net blocked 118.168.0.0/14 REJECT # Hinet.net blocked 122.118.0.0/16 REJECT # Hinet.net blocked 122.120.0.0/13 REJECT # Hinet.net blocked 125.224.0.0/13 REJECT # Hinet.net blocked 218.160.0.0/12 REJECT # Hinet.net blocked 220.128.0.0/12 REJECT # Hinet.net blocked
Re: TBIRD_SPOOF
On 14/02/13 14:48, John Hardin wrote: On Thu, 14 Feb 2013, Ned Slider wrote: Hi list, Is it just me or is TBIRD_SPOOF hitting pretty much all initial email sent by Thunderbird, not via a ML etc? That was an experimental rule that hasn't panned out and has been removed. It should go away with the next update. Many thanks John. And confirmed - it is now gone with the latest sa-update.
Re: [Fwd: Cron root@zoogz /usr/share/spamassassin/sa-update.cron -D 21 | tee -a /var/log/sa-update.log]
I have been seeing this in my log once a day for a few days now. What is the problem and how can I get it resolved. This is the latest log entry, but all were failures with amazonaws: http: GET http://rules.yerp.org.s3.amazonaws.com/rules/stage/3302013021221.tar.gz request failed: 403 Forbidden: ?xml version=1.0 encoding=UTF-8? ErrorCodeAccessDenied/CodeMessageAccess Denied/MessageRequestIdA1A070CD5615A700/RequestIdHostIdrg2byfiwxIKwAsqNLZ7JhD0pm3tiH/Avc59kZgu3fYFNOggFvfAMCrnfasV7FRIq/HostId/Error channel: could not find working mirror, channel failed -- View this message in context: http://spamassassin.1065346.n5.nabble.com/Fwd-Cron-root-zoogz-usr-share-spamassassin-sa-update-cron-D-2-1-tee-a-var-log-sa-update-log-tp103343p103539.html Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: [Fwd: Cron root@zoogz /usr/share/spamassassin/sa-update.cron -D 21 | tee -a /var/log/sa-update.log]
+1 for two days now On Thu, 2013-02-14 at 09:28 -0800, emmett wrote: I have been seeing this in my log once a day for a few days now. What is the problem and how can I get it resolved. This is the latest log entry, but all were failures with amazonaws: http: GET http://rules.yerp.org.s3.amazonaws.com/rules/stage/3302013021221.tar.gz request failed: 403 Forbidden: ?xml version=1.0 encoding=UTF-8? ErrorCodeAccessDenied/CodeMessageAccess Denied/MessageRequestIdA1A070CD5615A700/RequestIdHostIdrg2byfiwxIKwAsqNLZ7JhD0pm3tiH/Avc59kZgu3fYFNOggFvfAMCrnfasV7FRIq/HostId/Error channel: could not find working mirror, channel failed signature.asc Description: This is a digitally signed message part
