Re: How do I get delisted from SORBS? [OT]
On Fri, 22 Apr 2011 18:19:09 -0700 (PDT), maddog2020 landscat...@live.com wrote: Corpus here doesn't seem to understand that your can get blacklisted if you email host puts you on a shared server with a spammer. Therefore, by no fault of your own, you are effectively blacklisted. Furthermore, it is more than likely that the spammer on my shared server does not have an email address or even know about a domain i'm trying to send email to. So because this spammer-1 sends a message that SORBS consider's spam to XYZ.com, ABC.com blocks my email along with anyone else that is hosted on my server eventhough no one at any of the domains hosted on my server intends to spam ABC.com all because they use SORBS and are too lazy to create their own blacklist. What kind of sense does that make? dont know, but i agre ip blacklist will be last resort if postmaster@sender_domain.example.org does not solve it, to many hosts somply host 700 domains on one ip webserver and dont care of ip blacklists or even scan outgoing emails from that WEBSERVER ip suggested is to have diff ip for MAILSERVER and WEBSERVER or atleast scan outgoing mails As for SORBS, the easy way to get delisted and quit whining about how long it takes, is to *not* get listed in the first place. It's really a case of actions have consequences. Not careful in your output, don't expect any sympathy. atleast sorbs have still not listed my own ip as dynamic as spamhaus had for around 2 weeks ago, but it was simple me that used my postmaster @ junc dot org and acted on a respondse email to spamhaus and it was delisted in less then one hour use dnswl.org to help you out with pr domain whitelisting, and then hope sorbs use dnswl my ripe range is listed as mix of mobile dynamic and static ips and on top of that its less then 12 months old range, still keep problems of dns not working since its not unlisted in border routers and dns servers where the range is acl blackholed eg rfc-ignorant.org was not possible to use for my spammassassin, that is resolved now
Re: Spamassassin regex oddity
Hello Karsten, Friday, April 22, 2011, 4:31:25 PM, you wrote: KB The regex tester is broken. Anyone care to suggest a good tester that runs locally under XP -- Best regards, Niamhmailto:ni...@fullbore.co.uk pgpvKD5l1UlCk.pgp Description: PGP signature
Re: I messed up Bayes
On Sat, 23 Apr 2011 01:00:02 +0200, Karsten Bräckelmann wrote
On Fri, 2011-04-22 at 17:38 -0400, Dimitri Yioulos wrote:
Well, that does not explain why or how the
stock rules ended up in your site config dir --
neither why their version changes, though *not*
in sync with the installed sa-learn script.
Did you perhaps run sa-update with some bad
arguments, like target dir? It's not a symlink
either, right?
Do you perhaps have more than one sa-learn
script on your box?
'find' is your friend.
I did not run sa-learn with any bad arguments, nor
is it symlinked.
The first part (about the arguments) was about sa-update, not sa-learn.
The symlink was referring to /etc/mail/spamassassin -- I am trying to
find out the reason for the improperly placed stock rule-set in that
dir, and it's version mis-match.
As to the line length, sorry. Another list asked
me to change it to present length. What would be
appropriate? 80?
I was mostly joking, but what list would request you to use such short
lines? About 72-76 would be most appropriate, from a historic point of
view...
--
char *t=\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4;
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Karsten,
The whole piece about the improperly placed stock rule-set may have been my
doing. In
the way-back (se3ven years?), I,ll concede that I probably set that up
improperly as I
tried to learn, install, and configure sendmail, mailscanner, clamav, mailwatch,
spamassassin, etc. S now, I suppose, with the kind assistance of the list, I
can make
things right. This is an old set-up that,s due to be updated (new box, recent
OS,
up-to-date components, etc.) in during the next month anyway.
Using locate, I find only /usr/sbin/sa-update and its man page.
I'll fix the col length of my MUA, too :-)
Dimitri
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Re: Spamassassin regex oddity
On Sat, 2011-04-23 at 11:05 +0100, Niamh Holding wrote:
KB The regex tester is broken.
To be honest, it is not necessarily broken. I don't even know which tool
you used.
That comment should be understood as an emphasis of my previous detailed
explanation of the RE and the issues with it. Point is, the RE should
match exactly like SA did, despite the regex tester tool confirming your
expectation of the contrary.
Other than the tool being broken, it is of course entirely possible you
simply typo'ed either the RE or the Relay pseudo-header -- a newline
easily would have done that.
Anyone care to suggest a good tester that runs locally under XP
Perl.
--
char *t=\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4;
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: I messed up Bayes
On Sat, 2011-04-23 at 09:06 -0400, Dimitri Yioulos wrote:
The whole piece about the improperly placed stock rule-set may have
been my doing.
Possible. Though your OP doesn't really back that up. As I pointed out,
after your upgrading to 3.3.1, *and* again after reverting to 3.2.5, the
improperly placed stock rule-set in your site-config matched the
version. No way this is cruft inherited from years ago. Whereas the
sa-learn version also changed, but always was an older version than the
rules and the SA you just installed.
In the way-back (se3ven years?), I,ll concede that I probably set that
up improperly as I tried to learn, install, and configure sendmail,
mailscanner, clamav, mailwatch, spamassassin, etc. S now, I suppose,
with the kind assistance of the list, I can make things right. This
is an old set-up that,s due to be updated (new box, recent OS,
up-to-date components, etc.) in during the next month anyway.
Using locate, I find only /usr/sbin/sa-update and its man page.
Are you positive the locate database has been updated since your latest
changes? If not, that's precisely why I suggested to use 'find'.
--
char *t=\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4;
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: Spamassassin regex oddity
Hello Karsten, Saturday, April 23, 2011, 5:30:58 PM, you wrote: KB Other than the tool being broken, it is of course entirely possible you KB simply typo'ed either the RE or the Relay pseudo-header -- a newline KB easily would have done that. Cut'n'paste from locals.cf and the relevant header from an email in each case. KB Perl. Doesn't give me a text box to enter the text to test and another one to enter the regex being tested with an output showing the match or that there is no match. Something like http://www.lumadis.be/regex/test_regex.php but running locally. -- Best regards, Niamhmailto:ni...@fullbore.co.uk pgpGy2xHnFcwF.pgp Description: PGP signature
Re: Spamassassin regex oddity
On Sat, 2011-04-23 at 17:49 +0100, Niamh Holding wrote:
KB Other than the tool being broken, it is of course entirely possible you
KB simply typo'ed either the RE or the Relay pseudo-header -- a newline
KB easily would have done that.
Cut'n'paste from locals.cf and the relevant header from an email in
each case.
Exactly. Line breaks love to sneak in during copy-n-paste of long
lines. :) Besides, X-Spam-Relays-* are pseudo-headers, not part of the
email unless you specifically add_header them.
KB Perl.
Doesn't give me a text box to enter the text to test and another one
to enter the regex being tested with an output showing the match or
that there is no match.
Don't think text box, think file or variable instead.
If you keep on searching for a GUI tool, keep in mind you want one with
the tasty PCRE flavor of regex, not a cheap imitation with additives.
--
char *t=\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4;
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: Spamassassin regex oddity
Hello Karsten, Saturday, April 23, 2011, 6:23:51 PM, you wrote: KB Besides, X-Spam-Relays-* are pseudo-headers, not part of the KB email unless you specifically add_header them. I guess I must have done that to get them into every email :) -- Best regards, Niamhmailto:ni...@fullbore.co.uk pgpP4gsDWmoJ6.pgp Description: PGP signature
Re: Spamassassin regex oddity
On Sat, 2011-04-23 at 18:49 +0100, Niamh Holding wrote: Hello Karsten, Saturday, April 23, 2011, 6:23:51 PM, you wrote: KB Besides, X-Spam-Relays-* are pseudo-headers, not part of the KB email unless you specifically add_header them. I guess I must have done that to get them into every email :) Try these (best suggestion first) 1) Install a copy of Spamassassin on a development host, edit the rule you want to test in /etc/mail/spamassassin/local.cf and run: spamassassin test_message.txt Benefits: you're testing the rule you'll run in the environment it will run in, can also test meta-rules and can easily test against a real mail message. If you organise things correctly, you can keep all SA settings and local rules on the development machine and export them to the production server via a script and/or scp. I work this way and IME the time needed to set it up and write scripts to make rule development and testing simple is time well spent. 2) Try this online tester: http://www.solmetra.com/scripts/regex/ At least it defaults to PERL regexes, though it won't swallow a whole mail message easily. 3) grep -P 'regex to test' test_message.txt Benefits: easy to test against a real mail message. Runs on your own box. Demerit: the -P option is described as 'experimental' and may not yet implement all PCRE features. Martin
Re: Spamassassin regex oddity
On Sat, 2011-04-23 at 18:49 +0100, Niamh Holding wrote:
KB Besides, X-Spam-Relays-* are pseudo-headers, not part of the
KB email unless you specifically add_header them.
I guess I must have done that to get them into every email :)
Oh, you really got that from the mail's headers? Yeah, then your site
config should have some lines along
add_header all Relays-Untrusted _RELAYSUNTRUSTED_
and its variations. Adding them always probably is just wasting headers,
though. It's perfectly fine to enable it temporarily while chasing some
issues, or just generate it on demand when debugging or developing rules
like the one in your OP. You do not need to add_header them, to have the
rules working -- these pseudo-headers are always available to rules as
metadata, without effectively duplicating each and every Received
header.
To get these pseudo-headers on demand for rule development or debugging
your trustpath, just feed a sample through 'spamassassin -D' and grep
the STDERR output for the headers.
--
char *t=\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4;
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
