Re: Frequent "sysread not ready"-messages
On Monday 24 July 2006 00:54, Daryl C. W. O'Shea wrote: > Have a read through bug 4950. This might be it. If so, please > provide as much info and log info as you can. If not, please open a > new bug. > > http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4590 Right, it looks like the same symptoms, if it has the same cause, I can't tell. In particular, I have very little load on my systems, and it is sysread rather than syswrite that grabbed my attention. In fact, if I grep for syswrite, I can't see it occuring, so I guess it is a new bug. But since it happens many times every day here, I guess I can be of help in making straces and stuff. I very rarely do that, would some of the devs be on IRC today when I get back from work, in about 9 hours from now? Cheers, Kjetil -- Kjetil Kjernsmo Programmer / Astrophysicist / Ski-orienteer / Orienteer / Mountaineer [EMAIL PROTECTED] Homepage: http://www.kjetil.kjernsmo.net/ OpenPGP KeyID: 6A6A0BBC
Re: Google ad services redirector abuse
John D. Hardin wrote:
This wasn't detected as a redirector attack by 3.1.3, running
sa-update weekly:
{snippage}
http://www.google.com/pagead/iclk?sa=l&ai=Br3ycNQz5Q-fXBJGSiQLU0eDSAueHkArnhtWZAu-FmQWgjlkQAxgFKAg4AEDKEUiFOVD-4r2f-P8BoAGyqor_A8gBAZUCCapCCqkCxU7NLQH0sz4&num=5&adurl=http://1092229727:/https-www.paypal.com/webscrr/index.php";>Click
here to cancel your new email
address
Being a simple visible redirector, SA actually does detect it:
[7375] dbg: uri: cleaned html uri,
http://1092229727:/https-www.paypal.com/webscrr/index.php
[7375] dbg: uri: html domain, google.com
The problem is that SA doesn't then go on to do checks on the IP
1092229727 (CPE-65-26-26-95.kc.res.rr.com [65.26.26.95]) like it would
if it was in dotted-quad notation. Thus the hit on Sorbs' DUHL is avoided.
This is definitely a bug. Please open a bug report and attach a
complete sample to the bug.
http://issues.apache.org/SpamAssassin/
Daryl
Re: bayes sitewide
- Original Message -
From: "jdow" <[EMAIL PROTECTED]>
To:
Sent: Monday, July 24, 2006 1:28 AM
Subject: Re: bayes sitewide
> From: "Obantec Support" <[EMAIL PROTECTED]>
> > From: "Logan Shaw" <[EMAIL PROTECTED]>
> >> On Sun, 23 Jul 2006, Obantec Support wrote:
> >> > /etc/mail/spamassassin exists and is chown root.root and chmod 755
> >> >
> >> > bayes dir is chown root.root and chmod 770
> >>
> >> And SpamAssassin is running as what user? Can you "su" to
> >> that user and then cd to that directory, and read and write
> >> files there?
> >>
> >>- Logan
> >>
> >>
> >>
> >> --
> >> No virus found in this incoming message.
> >> Checked by AVG Anti-Virus.
> >> Version: 7.1.394 / Virus Database: 268.10.3/395 - Release Date:
21/07/2006
> >>
> >>
> >
> > Hi
> >
> > SA does not exist as a user. i am using spamd and in procmail i call
> > spamassassin
> >
> > system procmailrc
> >
> > DROPPRIVS=yes
> > :0fw
> > | /usr/bin/spamassassin
> > :0
> > * ^X-Spam-Status: Yes
> > $HOME/mail/spam
> >
> > got a feeling i should call | /usr/bin/spamc
>
> Um, Mark, what is the $LOGNAME parameter value within procmail when it
> is running the script above. THAT is the user who must have access to
> and own the /etc/mail/spamassassin directory. If the user under which
> procmail runs is root then you will find spamd via spamc handles it
> as nobody, I believe. And you do want to use spamc.
>
> {^_^}
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.1.394 / Virus Database: 268.10.3/395 - Release Date: 21/07/2006
>
>
$LOGNAME is the users name i assume as set by sendmail when i passes the
mail to the LDA
example (using spamc in the system side procmailrc)
Jul 24 09:06:58 proteus2 spamd[11709]: spamd: connection from
localhost.localdomain [127.0.0.1] at port 56913
Jul 24 09:06:58 proteus2 spamd[11709]: spamd: setuid to workan-mary
succeeded
Jul 24 09:06:58 proteus2 spamd[11709]: spamd: processing message
<[EMAIL PROTECTED]> for
workan-mary:700
Jul 24 09:06:59 proteus2 spamd[11709]: bayes: locker: safe_lock: cannot
create tmp lockfile
/etc/mail/spamassassin/bayes/bayes.lock.proteus2.obantec.net.11709 for
/etc/mail/spamassassin/bayes/bayes.lock: Permission denied
Jul 24 09:06:59 proteus2 spamd[11709]: spamd: clean message (0.0/5.0) for
workan-mary:700 in 1.0 seconds, 3165 bytes.
the 2 bayes files are chmod 0660 and when owned as root.root and not using
spamc bayes seems to work
as soon as i switch to spamc i get the above problem.
Mark
Re: New DNS Black list, White List, Yellow List
> > An ISP wpuld never be whitelisted anyhow. Whitelisting is for things > like banks and other institutions and organizations that produce no > spam. Yellowlisting is for ISPs so that they don't accidentally get > blacklisted. SPF is useless because few are using it due to the fact > that it just doesn't work. I too agree with your idea that we should start looking for ham in mails rather than looking for spam. This approach would help us tackle spam much more aggressively. But IMHO SPF works great and is much cleaner. A lot of banks/legitimate bulk email senders change their relay server. Many reasons for that. The most common is that they use a third party to relay their mails and these would keep changing You would have to delist your whitelisted ip before some spammer gets those. And since the whitelist is exposed there is a greater potential for abuse here. Thanks Ram
Re: New DNS Black list, White List, Yellow List
Ramprasad <[EMAIL PROTECTED]> writes: > A lot of banks/legitimate bulk email senders change their relay > server. Many reasons for that. The most common is that they use a third > party to relay their mails and these would keep changing Especially for banks and other high risk phishing targets, it would be much better if they did not do this. If all banks etc sent mail from a server whose IP address whose rDNS is xxx.bank.com and where xxx.bank.com resolves to the IP address from which the mail is sent, then it would considerably easier to detecting phishing and greatly improve the security for their customers.
Re: Google ad services redirector abuse
On Monday, July 24, 2006, 1:34:35 AM, Daryl O'Shea wrote: > Being a simple visible redirector, SA actually does detect it: > [7375] dbg: uri: cleaned html uri, > http://1092229727:/https-www.paypal.com/webscrr/index.php > [7375] dbg: uri: html domain, google.com > The problem is that SA doesn't then go on to do checks on the IP > 1092229727 (CPE-65-26-26-95.kc.res.rr.com [65.26.26.95]) like it would > if it was in dotted-quad notation. Thus the hit on Sorbs' DUHL is avoided. > This is definitely a bug. Please open a bug report and attach a > complete sample to the bug. > > http://issues.apache.org/SpamAssassin/ Note that we also blacklist phish site IPs on SURBLs, when they appear as IPs. In this case I blacklisted 1092229727 as 65.26.26.95, so hopefully any SA patch checks these in terms of dotted quad and not 1092229727. Arguments could probably be made for checking either, but for SURBLs, IPs are expected to be dotted quads only. Jeff C. -- Jeff Chan mailto:[EMAIL PROTECTED] http://www.surbl.org/
RE: New DNS Black list, White List, Yellow List
> -Original Message- > From: Graham Murray [mailto:[EMAIL PROTECTED] > Sent: Monday, July 24, 2006 7:44 AM > To: users@spamassassin.apache.org > Subject: Re: New DNS Black list, White List, Yellow List > > > Ramprasad <[EMAIL PROTECTED]> writes: > > > A lot of banks/legitimate bulk email senders change their relay > > server. Many reasons for that. The most common is that they use a > > third party to relay their mails and these would keep changing > > Especially for banks and other high risk phishing targets, it > would be much better if they did not do this. If all banks > etc sent mail from a server whose IP address whose rDNS is > xxx.bank.com and where xxx.bank.com resolves to the IP > address from which the mail is sent, then it would > considerably easier to detecting phishing and greatly improve > the security for their customers. Even if the banks used spf hardfail, it would at least stop phishing to ISP's ans servers that knew about SPF. (you could bump SPF_HARDFAIL score to 15, or use spf to block offending connection right in postfix!)
SPF breaks email forwarding
Michael Scheidell wrote: -Original Message- From: Graham Murray [mailto:[EMAIL PROTECTED]] Sent: Monday, July 24, 2006 7:44 AM To: users@spamassassin.apache.org Subject: Re: New DNS Black list, White List, Yellow List Ramprasad <[EMAIL PROTECTED]> writes: A lot of banks/legitimate bulk email senders change their relay server. Many reasons for that. The most common is that they use a third party to relay their mails and these would keep changing Especially for banks and other high risk phishing targets, it would be much better if they did not do this. If all banks etc sent mail from a server whose IP address whose rDNS is xxx.bank.com and where xxx.bank.com resolves to the IP address from which the mail is sent, then it would considerably easier to detecting phishing and greatly improve the security for their customers. Even if the banks used spf hardfail, it would at least stop phishing to ISP's ans servers that knew about SPF. (you could bump SPF_HARDFAIL score to 15, or use spf to block offending connection right in postfix!) Except = SPF breaks email forwarding. It requires that the world change how email is forwarded and that's not going to happen. Thus if a bank has a hard fail and someone with an account on my server gets email from an account that is forwarded then my server sees the email as coming from an illegitimate source.
Re: SPF breaks email forwarding
Marc Perkel wrote: Except = SPF breaks email forwarding. It requires that the world change how email is forwarded and that's not going to happen. Thus if a bank has a hard fail and someone with an account on my server gets email from an account that is forwarded then my server sees the email as coming from an illegitimate source. This was in response to the posted who suggested the fix was to make banks use a defined reverse dns (which would NOT break forwarding?) old news, see SRS. If you want to go on a spf jihad, I suggest you do some research. Also, and if you require all mail servers to only take mail from xxx.bank.com, what good is that? doesn't that break how everyone receives email? What about marketing campaigns (yes, we hate them) with spf records, the DNS admin can coordinate email marketing campaigns. you have to reach into every mail server in the world and so something like.. spf. -- Michael Scheidell, CTO SECNAP Network Security / www.secnap.com [EMAIL PROTECTED] / 1+561-999-5000, x 1131
RE: New DNS Black list, White List, Yellow List
Title: RE: New DNS Black list, White List, Yellow List > -Original Message- > From: Ramprasad [mailto:[EMAIL PROTECTED]] > Sent: Monday, July 24, 2006 7:08 AM > To: Marc Perkel > Cc: John Andersen; spamassassin-users > Subject: Re: New DNS Black list, White List, Yellow List > > > > > > > An ISP wpuld never be whitelisted anyhow. Whitelisting is for things > > like banks and other institutions and organizations that produce no > > spam. Yellowlisting is for ISPs so that they don't accidentally get > > blacklisted. SPF is useless because few are using it due to the fact > > that it just doesn't work. > > I too agree with your idea that we should start looking for > ham in mails > rather than looking for spam. This approach would help us tackle spam > much more aggressively. Aren't we dealing with a boolean data set? Its either spam or ham. Which you train your software to look for doesn't really matter. Speaking from URIBL work: 1) Yes you need logins to identify users. And you need a group of great people in the project. 2) Certain listings do need expiration times. 3) Delist request take up FAR more time then listings. Be ready to handle those. 4) The word "White" sends spammers frothing at the mouth. They will attempt to game your setup. 5) You need a whole infrastructure of mirrors if it goes real world live. 6) The hatred of the NY Yankees by Red Sox fans is ever increasing. I wish you the best of luck in the project. Chris Santerre SysAdmin and SARE/URIBL ninja http://www.uribl.com http://www.rulesemporium.com
Re: New DNS Black list, White List, Yellow List
Chris Santerre wrote: Aren't we dealing with a boolean data set? Its either spam or ham. Which you train your software to look for doesn't really matter. Actually not. I look at email differently. I process 4 different grades of spam and 3 grades of ham. As to my Black/White/yellow listing there are 3 kinds of email. Ham, Spam, and yet to be determined. You pass on the ham, block the spam, and send the rest on to the next process to further evaluate it. Ultimately there are emails that end up undermined and you pass them on to the end user. But in my mind there's a big difference between a message determined to be ham and a message that fails to be determined as spam.
SPAM: Increase in targeted spams
Title: SPAM: Increase in targeted spams One of our users received a spam today from genutrust .com, URL in spam CHICHIMECA .COM This spam was VERY targeted. User's first and last name, complete address, and her phone number. She informed me her phone number was listed with initials of her and her husband, not her full name. So she has no idea where they got this info. It was already caught as spam, but it definetly has the user a bit nervous. Looks like the targeted spams to bypass bayes filters is on the rise. Anyone else see one of these from genutrust? Chris Santerre SysAdmin and SARE/URIBL ninja http://www.uribl.com http://www.rulesemporium.com
Re: [SPAM] Re: Google ad services redirector abuse
On Mon, 24 Jul 2006, Daryl C. W. O'Shea wrote: > > > href="http://www.google.com/pagead/iclk?sa=l&ai=Br3ycNQz5Q-fXBJGSiQLU0eDSAueHkArnhtWZAu-FmQWgjlkQAxgFKAg4AEDKEUiFOVD-4r2f-P8BoAGyqor_A8gBAZUCCapCCqkCxU7NLQH0sz4&num=5&adurl=http://1092229727:/https-www.paypal.com/webscrr/index.php";>Click > > here to cancel your new email > > address > > Being a simple visible redirector, SA actually does detect it: > > [7375] dbg: uri: cleaned html uri, > http://1092229727:/https-www.paypal.com/webscrr/index.php > [7375] dbg: uri: html domain, google.com Ah, good. I assume that means the redirector_pattern I suggested is not necessary? > The problem is that SA doesn't then go on to do checks on the IP > 1092229727 (CPE-65-26-26-95.kc.res.rr.com [65.26.26.95]) like it > would if it was in dotted-quad notation. Thus the hit on Sorbs' > DUHL is avoided. > > This is definitely a bug. Please open a bug report and attach a > complete sample to the bug. roger wilco. -- John Hardin KA7OHZICQ#15735746http://www.impsec.org/~jhardin/ [EMAIL PROTECTED]FALaholic #11174pgpk -a [EMAIL PROTECTED] key: 0xB8732E79 - 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- To prevent conflict and violence from undermining development, effective disarmament programmes are vital... -- the UN, who "doesn't want to confiscate guns" --- Today: The 37th anniversary of Apollo 11 landing on the Moon
Bug in sa-learn (Debian :3.0.3-2sarge1)
I have found this in the archives, but I did not find a solution yet.
On a mailserver that I have upgraded to Debian Sarge, the following
warning appears when I am running sa-learn:
Parsing of undecoded UTF-8 will give garbage when decoding entities at
/usr/share/perl5/Mail/SpamAssassin/HTML.pm line 182.
I have found the following patch but it does not apply successfully
using "patch":
--- lib/Mail/SpamAssassin/HTML.pm (revision 178588)
+++ lib/Mail/SpamAssassin/HTML.pm (working copy)
@@ -107,6 +107,15 @@
],
marked_sections => 1);
+ # enable UTF-8 mode,
+ # http://search.cpan.org/~gaas/HTML-Parser-3.45/Parser.pm#$p-%3Eutf8_mode ,
+ # if we're running perl 5.8 and HTML::Parser supports it. bug 4046.
+ if ($] >= 5.008 && $self->can("utf8_mode")) {
+if (!eval { $self->utf8_mode(); 1; }) {
+ dbg ("html: failed to enable UTF-8 mode (perl ver $] h:p ver
$HTML::Parser::VERSION)");
+}
+ }
+
$self;
}
How do I solve this?
Regards
Johann
--
Johann Spies Telefoon: 021-808 4036
Informasietegnologie, Universiteit van Stellenbosch
"Be not deceived; God is not mocked; for whatsoever a
man soweth, that shall he also reap."
Galatians 6:7
Re: SPF breaks email forwarding
Michael Scheidell <[EMAIL PROTECTED]> writes: > Also, and if you require all mail servers to only take mail from > xxx.bank.com, what good is that? doesn't that break how everyone > receives email? No. It just rings very loud alarm bells when an email claiming to be from the bank comes from a server other than *.bank.com. It does, of course, require the user to check but this can be done either automatically by something like Spamassassin or using the Mk1 human eyeball to examine the message headers. It would not be necessary for the user to examine the headers of every message, just those claiming to come from 'high risk' (to the recipient) senders.
Re: SPF breaks email forwarding
> Except = SPF breaks email forwarding. It requires that the world > change how email is forwarded and that's not going to happen. Thus if > a bank has a hard fail and someone with an account on my server gets > email from an account that is forwarded then my server sees the email > as coming from an illegitimate source. > I know this is a troll subject Yes SPF breaks email forwarding, so does PTR checking ( which never was a great idea IMHO ). Every technique has some drawbacks. SPF has some but is still better than the rest When you want add security to an inherently insecure medium you cant say I will not change my servers. You want to put a .forward and receive mails from banks, get you mail- admin to use SRS. What is unreasonable in that ? Thanks Ram
Re: SPF breaks email forwarding
Ramprasad wrote: I know this is a troll subject Yes SPF breaks email forwarding, so does PTR checking ( which never was a great idea IMHO ). Every technique has some drawbacks. SPF has some but is still better than the rest When you want add security to an inherently insecure medium you cant say I will not change my servers. You want to put a .forward and receive mails from banks, get you mail- admin to use SRS. What is unreasonable in that ? you hit the nail on the head: If you want things to change, you have to change things. You cannot fix SMTP without breaking something. -- Michael Scheidell, CTO SECNAP Network Security / www.secnap.com [EMAIL PROTECTED] / 1+561-999-5000, x 1131
Re: SPF breaks email forwarding
But I have no control over the servers that forward to me. Thus SPF is useless. Michael Scheidell wrote: Ramprasad wrote: I know this is a troll subject Yes SPF breaks email forwarding, so does PTR checking ( which never was a great idea IMHO ). Every technique has some drawbacks. SPF has some but is still better than the rest When you want add security to an inherently insecure medium you cant say I will not change my servers. You want to put a .forward and receive mails from banks, get you mail- admin to use SRS. What is unreasonable in that ? you hit the nail on the head: If you want things to change, you have to change things. You cannot fix SMTP without breaking something.
Re: SPF breaks email forwarding
Marc Perkel wrote: But I have no control over the servers that forward to me. Thus SPF is useless. so, again, bottom line: SMTP is broken. has been, phishing, forgeries, email viruses prove it. YOU fix it without breaking something. It can't be done. All you can do is compromise., and ps, SPF doesn't break forwarding, its the other way around: forwarding breaks SPF. If you can't come up with a proposal (something SPAML list has argued about for 12 years) to fix it without breaking it than there really is no need to attempt to educate you any further. Turn off SMTP, firewall port 25, no more email problems. -- Michael Scheidell, CTO SECNAP Network Security / www.secnap.com [EMAIL PROTECTED] / 1+561-999-5000, x 1131
Re: Google ad services redirector abuse
Jeff Chan wrote: On Monday, July 24, 2006, 1:34:35 AM, Daryl O'Shea wrote: Being a simple visible redirector, SA actually does detect it: [7375] dbg: uri: cleaned html uri, http://1092229727:/https-www.paypal.com/webscrr/index.php [7375] dbg: uri: html domain, google.com The problem is that SA doesn't then go on to do checks on the IP 1092229727 (CPE-65-26-26-95.kc.res.rr.com [65.26.26.95]) like it would if it was in dotted-quad notation. Thus the hit on Sorbs' DUHL is avoided. This is definitely a bug. Please open a bug report and attach a complete sample to the bug. http://issues.apache.org/SpamAssassin/ Note that we also blacklist phish site IPs on SURBLs, when they appear as IPs. In this case I blacklisted 1092229727 as 65.26.26.95, so hopefully any SA patch checks these in terms of dotted quad and not 1092229727. Arguments could probably be made for checking either, but for SURBLs, IPs are expected to be dotted quads only. Yeah, the dotted quad would be checked against SURBLs too. I just mentioned Sorbs' DUHL since it was the only one I got a hit on 65.26.26.95 from. Daryl
Re: [SPAM] Re: Google ad services redirector abuse
John D. Hardin wrote: On Mon, 24 Jul 2006, Daryl C. W. O'Shea wrote: I assume that means the redirector_pattern I suggested is not necessary? Right. Anything that would match (https?:\/\/.*) is already taken care of by SA internally. The problem is that SA doesn't then go on to do checks on the IP 1092229727 (CPE-65-26-26-95.kc.res.rr.com [65.26.26.95]) like it would if it was in dotted-quad notation. Thus the hit on Sorbs' DUHL is avoided. This is definitely a bug. Please open a bug report and attach a complete sample to the bug. roger wilco. Thanks. http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5006 Daryl
RE: SPAM: Increase in targeted spams
Title: SPAM: Increase in targeted spams From: Chris Santerre [mailto:[EMAIL PROTECTED] Sent: Monday, July 24, 2006 10:19 AMTo: Spaml (E-mail); SaTalk (E-mail)Subject: SPAM: Increase in targeted spams One of our users received a spam today from genutrust .com, URL in spam CHICHIMECA .COM This spam was VERY targeted. User's first and last name, complete address, and her phone number. She informed me her phone number was listed with initials of her and her husband, not her full name. So she has no idea where they got this info. Let me Guess: she has reposed to 'friends' who want to keep up with her in their 'private' social network? Something like linkedin? At least it will cost the spammer some cpu cycles, sending out each one, one at a time. Bayesian, and 'section' checksums like for DCC and razor should help block some of this, even if they use the person's real name/phone number.
Re: SPF breaks email forwarding
Domainkeys does less harm to forwarded messages than spf - a forwarder just has to put a Sender: header there, rother than implement srs Wolfgang Hamann >> >> Michael Scheidell wrote: >> >> -Original Message- >> >> From: Graham Murray [mailto:[EMAIL PROTECTED] >> >> Sent: Monday, July 24, 2006 7:44 AM >> >> To: users@spamassassin.apache.org >> >> Subject: Re: New DNS Black list, White List, Yellow List >> >> >> >> >> >> Ramprasad <[EMAIL PROTECTED]> writes: >> >> >> >> >> >>> A lot of banks/legitimate bulk email senders change their relay >> >>> server. Many reasons for that. The most common is that they use a >> >>> third party to relay their mails and these would keep changing >> >>> >> >> Especially for banks and other high risk phishing targets, it >> >> would be much better if they did not do this. If all banks >> >> etc sent mail from a server whose IP address whose rDNS is >> >> xxx.bank.com and where xxx.bank.com resolves to the IP >> >> address from which the mail is sent, then it would >> >> considerably easier to detecting phishing and greatly improve >> >> the security for their customers. >> >> >> > >> > Even if the banks used spf hardfail, it would at least stop phishing to >> > ISP's ans servers that knew about SPF. >> > >> > (you could bump SPF_HARDFAIL score to 15, or use spf to block offending >> > connection right in postfix!) >> > >> >> Except = SPF breaks email forwarding. It requires that the world change >> how email is forwarded and that's not going to happen. Thus if a bank >> has a hard fail and someone with an account on my server gets email from >> an account that is forwarded then my server sees the email as coming >> from an illegitimate source. >> >>
meta rule format
Am running SpamAssassin 3.1.2 on Windows 2003 Server. I have written a meta rule and i want it to only hit if it hits the first rule AND one of the three in brackets. This syntax doesn't seem to work as it hits when it hits one of the last three but not the first one. meta DRUGS_RX (__RX + (__SPEN_DING || __PRESCRIPTION || __SAVE)) Thanks Ben
Re: SPF breaks email forwarding
On Mon, 24 Jul 2006, Ramprasad wrote:
> > Except = SPF breaks email forwarding. It requires that the world
> > change how email is forwarded and that's not going to happen. Thus if
> > a bank has a hard fail and someone with an account on my server gets
> > email from an account that is forwarded then my server sees the email
> > as coming from an illegitimate source.
[snip..]
> Yes SPF breaks email forwarding, so does PTR checking ( which never was
> a great idea IMHO ). Every technique has some drawbacks. SPF has some
> but is still better than the rest
> When you want add security to an inherently insecure medium you cant say
> I will not change my servers.
> You want to put a .forward and receive mails from banks, get you mail-
> admin to use SRS. What is unreasonable in that ?
An even better way to deal with this scenario; tell your customer:
"When you forward mail thru a 3'rd party it introduces potential
security risks. Your bank is not willing to tolerate those risks and
demands (via SPF-hardfail) that their messages get delivered directly
to their customers. When you (the customer) change ISPs you need to
go to your bank-account's profile and update the e-mail address.
To maintain security and reliability of delivery you should want to
do this."
That little dialog should impress the customer with your sincerity
and their bank's commitment to security (as well as redirect any
potential complaints to the bank, the bank made us do this ;).
It's also the simple truth. The analogy would be, if you move you
file a change-of-address with your bank, you don't trust the people
at your old apartment to always forward your bank statements to
your new home.
Dave
--
Dave Funk University of Iowa
College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include
Better is not better, 'standard' is better. B{
Re: SPF breaks email forwarding
Hi, it seems to me that one of the big problems of email is the fact that email clients more or less hide the email address in favor of the display name, and that many users seem to lack the knowledge to check, let alone understand, message headers I guess most people should be able to notice the obvious discrepancy between sender address and display name that is present in many unwanted emails, if they were just seeing them Wolfgang Hamann >> Michael Scheidell <[EMAIL PROTECTED]> writes: >> >> > Also, and if you require all mail servers to only take mail from >> > xxx.bank.com, what good is that? doesn't that break how everyone >> > receives email? >> >> No. It just rings very loud alarm bells when an email claiming to be >> from the bank comes from a server other than *.bank.com. It does, of >> course, require the user to check but this can be done either >> automatically by something like Spamassassin or using the Mk1 human >> eyeball to examine the message headers. It would not be necessary for >> the user to examine the headers of every message, just those claiming >> to come from 'high risk' (to the recipient) senders. >>
RE: meta rule format
Ben Wylie wrote: > Am running SpamAssassin 3.1.2 on Windows 2003 Server. > > I have written a meta rule and i want it to only hit if it hits the > first rule AND one of the three in brackets. > > This syntax doesn't seem to work as it hits when it hits one of the > last three but not the first one. > > meta DRUGS_RX (__RX + (__SPEN_DING || __PRESCRIPTION || __SAVE)) meta DRUGS_RX (__RX && (__SPEN_DING || __PRESCRIPTION || __SAVE)) -- Bowie
Re: meta rule format
On Mon, Jul 24, 2006 at 07:25:23PM +0100, Ben Wylie wrote: > This syntax doesn't seem to work as it hits when it hits one of the last > three but not the first one. > > meta DRUGS_RX (__RX + (__SPEN_DING || __PRESCRIPTION || __SAVE)) You want a boolean and (&&). The way you've done it the "+" looks like a boolean or (||) because what comes out is something similar to: 0 + (0 || 0 || 1) == 1 whereas 0 && (0 || 0 || 1) == 0 -- Randomly Generated Tagline: "As for SUVs being used as family cars: If a family is too large to fit into a fuel efficient automobile it doesn't need an SUV, it needs birth control." - Unknown pgpJK7eUOchNe.pgp Description: PGP signature
Re: Bug in sa-learn (Debian :3.0.3-2sarge1)
This is just a warning that you can ignore. If it bothers you, the best solution would be to
upgrade to 3.1.3. Alternately, you could try this on your lib/Mail/SpamAssassin/HTML.pm:
182c182,189
< $hp->parse(pack ('C0A*', $text));
---
> {
> local $SIG{__WARN__} = sub {
> warn @_ unless (defined $_[0] && $_[0] =~ /^Parsing of undecoded UTF-/);
> };
>
> $hp->parse(pack ('C0A*', $text));
> }
>
I don't know if this will apply cleanly to your Debian version, though. If not, you should probably
be able to edit it manually.
Johann Spies wrote:
I have found this in the archives, but I did not find a solution yet.
On a mailserver that I have upgraded to Debian Sarge, the following
warning appears when I am running sa-learn:
Parsing of undecoded UTF-8 will give garbage when decoding entities at
/usr/share/perl5/Mail/SpamAssassin/HTML.pm line 182.
I have found the following patch but it does not apply successfully
using "patch":
--- lib/Mail/SpamAssassin/HTML.pm (revision 178588)
+++ lib/Mail/SpamAssassin/HTML.pm (working copy)
@@ -107,6 +107,15 @@
],
marked_sections => 1);
+ # enable UTF-8 mode,
+ # http://search.cpan.org/~gaas/HTML-Parser-3.45/Parser.pm#$p-%3Eutf8_mode ,
+ # if we're running perl 5.8 and HTML::Parser supports it. bug 4046.
+ if ($] >= 5.008 && $self->can("utf8_mode")) {
+if (!eval { $self->utf8_mode(); 1; }) {
+ dbg ("html: failed to enable UTF-8 mode (perl ver $] h:p ver
$HTML::Parser::VERSION)");
+}
+ }
+
$self;
}
How do I solve this?
Regards
Johann
DNS timeout and debugging
I am running SpamAssassin 3.1.2 on Windows 2003 Server. Is there any way for me to change the DNS timeout period? Is there a way for me to increase debugging info on DNSBL tests? When for some reason, if all DNS tests work, no positive results are given, and only if it times out on some of them will the others give me positive results. For example i would like it to put a line in the log when it positively gets a hit on a DNSBL test. Thanks Ben
Re: meta rule format
On Mon, 24 Jul 2006 19:25:23 +0100, Ben Wylie <[EMAIL PROTECTED]> wrote: >Am running SpamAssassin 3.1.2 on Windows 2003 Server. > >I have written a meta rule and i want it to only hit if it hits the >first rule AND one of the three in brackets. > >This syntax doesn't seem to work as it hits when it hits one of the last >three but not the first one. > >meta DRUGS_RX (__RX + (__SPEN_DING || __PRESCRIPTION || __SAVE)) > >Thanks >Ben Are the base rules not catching those? It's very, very rare for me to see a mail that would tag that rule come through the basic rules in SA. Maybe you should update to 3.1.3 and run sa-update? Better still, stick SA on a nix box, it does the job so much better. You may also want to look at http://www.rulesemporium.com/rules.htm though Im pretty sure the anti-drug is now part of the base SA rule set. HTH Nigel
Re: DNS timeout and debugging
On Mon, 24 Jul 2006 22:12:14 +0100, Ben Wylie <[EMAIL PROTECTED]> wrote: >I am running SpamAssassin 3.1.2 on Windows 2003 Server. > >Is there any way for me to change the DNS timeout period? > >Is there a way for me to increase debugging info on DNSBL tests? >When for some reason, if all DNS tests work, no positive results are >given, and only if it times out on some of them will the others give me >positive results. >For example i would like it to put a line in the log when it positively >gets a hit on a DNSBL test. > >Thanks >Ben rbl_timeout in your local.cf http://spamassassin.taint.org/doc/Mail_SpamAssassin_Conf.html
Re: Increase in targeted spams
From: "Chris Santerre" <[EMAIL PROTECTED]>
One of our users received a spam today from genutrust .com, URL in spam
CHICHIMECA .COM
This spam was VERY targeted. User's first and last name, complete address,
and her phone number. She informed me her phone number was listed with
initials of her and her husband, not her full name. So she has no idea where
they got this info.
It was already caught as spam, but it definetly has the user a bit nervous.
Looks like the targeted spams to bypass bayes filters is on the rise.
Anyone else see one of these from genutrust?
If she includes her address in signature blocks on emails a good
harvesting program on a mailing list will find it. Then some use of
things such as reverse lookup phone books will give phone number
and last name associated with it. And usually email signatures include
the first name.
It is not particularly difficult for people to do if the phone number
is listed at all and is not entirely pseudonymous in nature. That is
why I tend to be rather vague about where I live, South West corner
of San Bernardino County suffices for any sane needs. And I'm not in
any phone book. That does make it more difficult for targeted spam
operations.
(And the pseudonymous listing with a phone that has a hold button
is great fun when they ask for Fran Finkels or something on our
phone. "Oh, she's in the bathroom at the moment. I'll let her know
about your call. Please hold. ")
{^_^}
