Re: SOUGHT 2.0
On 12/05/2014 01:15 AM, Ian Zimmerman wrote: On Thu, 04 Dec 2014 22:41:13 +0100, Axb axb.li...@gmail.com wrote: Axb To be able to create usable rules, several times/day I need feeds Axb to spit *at least* +150k/day. As I don't have the data 150k of what? Bytes? Emails? Tokens? Sorry, thought this was obvious... SOUGHT type rule generation extracts txt strings from spams so it means +150k spams/day
Re: SOUGHT 2.0
On 12/05/2014 02:27 AM, Benny Pedersen wrote: On 4. dec. 2014 22.42.42 Axb axb.li...@gmail.com wrote: To be able to create usable rules, several times/day I need feeds to spit *at least* +150k/day. As I don't have the data So not possible to make it run decentraly ? This imho another precompiled problem I normally wouldn't reply to such a msg but It's possible to run decentraly. The basic code in SVN - you're welcome to make it your project and spend the next year getting it to happen,
Re: ancient perl versions
The problem is Roundcube. It does not insert soft line breaks as per the MIME Quoted-Printable encoding. There's a lot of MIME stuff that Roundcube doesn't do very well, it's just not a very good web mail interface. I'm always surprised at how vehemently people defend it. Many email clients can be set to automatically wrap received text. Including the one I'm using now. But I don't turn that feature on because I want to give the SENDER of the message control over text positioning. I feel that if the sender has laid out their email a particular way, they have a reason for it. ASCII with a fixed font like Courier has always been the standard for email, and you can do stuff like this with it: -- --- \ | Network router |---| NID |--- -- --- / Which is far, far quicker and more efficient than attaching some visio drawing that I probably don't have a viewer for loaded on whatever system I'm using. And I won't even get into indentation of code in Email messages. As such, senders who are clever and careful and make use of fixed width fonts and ASCII text can do a heck of a lot quicker communicating and more understandable than a bunch of HTMLized stuff using a proportional spaced font that munges drawings, and destroys indentation, and such people have a damn good reason at times to send out text that is soft broken at specific places. So if I turn on Word Wrap like Android does I have just succeeded in shooting myself in the foot when I get an email from the smart people. So I assume the sender knows what they are doing and do I don't try to second guess them by wrapping their stuff. If you want to send out email that looks like it's been beaten by an ugly stick with weird looking fonts and lines that run on forever and ever, with no thought to positioning and making it look readable, as far as I'm concerned, that's not a reflection on me, it's a reflection on you. I'm not going to change my config to clean up your email, particularly when your the only one doing it, no more than I would waste time tucking in the shirt and straightening the tie and shining the shoes of a salesguy who showed up to sell me something. It's also not really my job to explain the concept of the blind leading the blind and relate that to the fact that nobody else has ever yadda yadda yadda but I'll do it anyway - it wasn't too long ago when the vast majority of people thought the world was flat, but that merely meant that the vast majority of people were ignorant - just like the vast majority of people who have never brought it up to you before are just as ignorant of line wrapping. After all, it is an esoteric subject. Ted On 12/4/2014 10:20 PM, Noel Butler wrote: On 05/12/2014 14:40, Dave Pooser wrote: On 12/4/14 10:27 PM, Nick Edwardsnick.z.edwa...@gmail.com mailto:nick.z.edwa...@gmail.com wrote: It's also not wrapping the text at all. it wraps fine here Look at the last roundcube post, the one sent at 01:06 GMT. The line of quoted text runs 273 columns without a linewrap. What client are you using? roundcube - wraps Evolution - wraps the font size btw is identical to yours on both. only two I use for this a/c forwarded that message in question to my private address, and checked it in android tablet and phone, both wrap. since no one has ever brought this up with me before, I'm placing this as not my problem to resolve.
Re: ancient perl versions
pffft I see no problem, as like most developers if you cant reproduce it, then its nothing to bother about, after all this time 2 ppl dont like a font or whatever, your pissing up the wrong tree if you think I have a care factor about changing things when i cant reproduce it. time to move along ... On 05/12/2014 19:46, Ted Mittelstaedt wrote: The problem is Roundcube. It does not insert soft line breaks as per the MIME Quoted-Printable encoding. There's a lot of MIME stuff that Roundcube doesn't do very well, it's just not a very good web mail interface. I'm always surprised at how vehemently people defend it.
Re: ancient perl versions
On 12/05/2014 09:38 AM, Noel Butler wrote: pffft I see no problem, as like most developers if you cant reproduce it, then its nothing to bother about, after all this time 2 ppl dont like a font or whatever, your pissing up the wrong tree if you think I have a care factor about changing things when i cant reproduce it. time to move along ... You're reproducing it for me ... e-mails from you have a hard-to-read small font here also. Not from anyone else - just you.
Re: ancient perl versions
Am 05.12.2014 um 16:47 schrieb Mike Grau: On 12/05/2014 09:38 AM, Noel Butler wrote: pffft I see no problem, as like most developers if you cant reproduce it, then its nothing to bother about, after all this time 2 ppl dont like a font or whatever, your pissing up the wrong tree if you think I have a care factor about changing things when i cant reproduce it. time to move along ... You're reproducing it for me ... e-mails from you have a hard-to-read small font here also. Not from anyone else - just you be careful or you end attacked and blacklisted as we still are because i did not accept the personal attack and you have no right to ask anybody while playing manner cop http://www.gossamer-threads.com/lists/apache/dev/435100#435100 http://www.gossamer-threads.com/lists/apache/dev/435104 http://www.gossamer-threads.com/lists/apache/dev/435162#435162 signature.asc Description: OpenPGP digital signature
Re: ancient perl versions
On Sat, 6 Dec 2014, Noel Butler wrote: pffft I see no problem, !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN htmlbody style=3D'font-size: 10pt' ppffft/p -- 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 --- Individual liberties are always loopholes to absolute authority. --- 10 days until Bill of Rights day
Re: SOUGHT 2.0
Axb wrote: On 12/05/2014 01:15 AM, Ian Zimmerman wrote: On Thu, 04 Dec 2014 22:41:13 +0100, Axb axb.li...@gmail.com wrote: Axb To be able to create usable rules, several times/day I need feeds Axb to spit *at least* +150k/day. As I don't have the data 150k of what? Bytes? Emails? Tokens? Sorry, thought this was obvious... SOUGHT type rule generation extracts txt strings from spams so it means +150k spams/day It seems to work reasonably well for me with ~2-3K each ham and spam, and even provides a handful of subrules even with ~225 spam subtype messages. (I generate a number of sets of rules with different subtypes of spam.) It's probably not nearly as *effective* as it could be with larger working sets. -kgd
Re: SOUGHT 2.0
On 12/05/2014 05:20 PM, Kris Deugau wrote: Axb wrote: On 12/05/2014 01:15 AM, Ian Zimmerman wrote: On Thu, 04 Dec 2014 22:41:13 +0100, Axb axb.li...@gmail.com wrote: Axb To be able to create usable rules, several times/day I need feeds Axb to spit *at least* +150k/day. As I don't have the data 150k of what? Bytes? Emails? Tokens? Sorry, thought this was obvious... SOUGHT type rule generation extracts txt strings from spams so it means +150k spams/day It seems to work reasonably well for me with ~2-3K each ham and spam, and even provides a handful of subrules even with ~225 spam subtype messages. (I generate a number of sets of rules with different subtypes of spam.) It's probably not nearly as *effective* as it could be with larger working sets. Agreed. ... I use about 5-15k from the last 8 hrs (amount varies dramatically) per rule gen run *for local* use, but that's hardly representative for global coverage.
Re: ancient perl versions
On Fri, 2014-12-05 at 09:47 -0600, Mike Grau wrote: On 12/05/2014 09:38 AM, Noel Butler wrote: pffft I see no problem, as like most developers if you cant reproduce it, then its nothing to bother about, after all this time 2 ppl dont like a font or whatever, your pissing up the wrong tree if you think I have a care factor about changing things when i cant reproduce it. time to move along ... You're reproducing it for me ... e-mails from you have a hard-to-read small font here also. Not from anyone else - just you. I've noticed in the past that supposedly identical fonts are scaled differently by some programs. It seems that in this case Evolution doesn't show this behaviour, at least with example text that has been sent to this list and using fonts included in Fedora 20 (but who knows what it might do under Fedora 21 if the fonts change?), so it would be interesting to know if there are any other combinations of OS+MUA+font that always show it. Similar comments apply to line wrapping. There are some newsreaders and MUAs that give the receiving user control over line wrapping. The Pan newsreader has a 'Wrap lines' toggle while Evolution sometimes leaves paragraphs that it thinks are preformatted as single long lines, fixed by highlighting them and clicking 'Formatted' followed by 'Unformatted' on the Format dropdown menu. So, obviously, there *are* newsreaders and MUAs that insist on sending paragraphs as single very long lines or (1) newsreaders and MUAs would not have linewrapping controls and (2) I would not know how to deal with these single line paragraphs. Its also possible that the owners and operators of the offending programs don't know that this happens because they never see the paragraph as a single long line because the program always wraps when it shows you, even when its displaying or printing the message in raw format. It would be interesting to know what they see if they look at messages with less, which doesn't wrap lines by default, without giving their MUA a chance to reformat the message on its way to being looked at by less. Martin
text/html rendering (was Re: ancient perl versions)
Since most mail clients that send HTML mail also send a text/plain part with similar content, my filter looks for messages with the structure: multipart/alternative text/plain text/html and converts that little subtree to just: text/plain There is occasionally some loss of information, but it works just fine 99.9% of the time. Certainly, it has worked for every posting on this list. Regards, David.
Re: text/html rendering (was Re: ancient perl versions)
On Dec 5, 2014 at 11:34 -0500, David F. Skoll wrote: =Since most mail clients that send HTML mail also send a text/plain part with =similar content, my filter looks for messages with the structure: = = multipart/alternative = text/plain = text/html = =and converts that little subtree to just: = =text/plain = =There is occasionally some loss of information, but it works just =fine 99.9% of the time. Certainly, it has worked for every =posting on this list. Been a long time since I dug into MIME details and MUA display formating, but don't forget about format=flowed when it comes to Content-Type: Text/Plain and line wrapping. And/or, Content-transfer-encoding: quoted-printable with Content-Type: Text/Plain, too. -- *** Derek DigetOffice of Information Technology Western Michigan University - Kalamazoo Michigan USA - www.wmich.edu/ ***
Re: Multiple subject headers - most blank
On 12/4/2014 10:22 AM, Gibbs, David wrote: I've seen a number of spam messages come through with multiple header lines ... some of them are blank. Any suggestions for a rule to trap this? FWIW: here's the rule I came up with ... seems to work adequately. header __COUNT_SUBJ Subject =~ /.*/ tflags __COUNT_SUBJ multiple meta DMG_MULT_SUBJ (__COUNT_SUBJ 2) score DMG_MULT_SUBJ 1.0 describe DMG_MULT_SUBJ Message has more than one subject header Although the __COUNT_SUBJ rule isn't behaving as I would expect it. If the meta rule says 1, and the message only has one subject, the rule is activated. That's why I have it set to 2 instead. david -- IBM i on Power Systems: For when you can't afford to be out of business! I'm riding a metric century (100 km / 62 miles) in the 2015 American Diabetes Association's Tour de Cure to raise money for diabetes research, education, advocacy, and awareness. You can make a tax deductible donation to my ride by visiting http://email.diabetessucks.net. My goal is $5500 but any amount is appreciated. See where I get my donations from ... visit http://email.diabetessucks.net/mapdonations.php for an interactive map (it's a geeky thing).
Re: Multiple subject headers - most blank
On Fri, 5 Dec 2014, Gibbs, David wrote: On 12/4/2014 10:22 AM, Gibbs, David wrote: I've seen a number of spam messages come through with multiple header lines ... some of them are blank. Any suggestions for a rule to trap this? FWIW: here's the rule I came up with ... seems to work adequately. header __COUNT_SUBJ Subject =~ /.*/ You might want to be a little bit more paranoid and explicitly anchor that: header __COUNT_SUBJ Subject =~ /^.*$/ I know .* is greedy and shouldn't overlap on multiple matches, but this helps make sure. -- 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 --- Our government wants to do everything it can for the children, except sparing them crushing tax burdens. --- 10 days until Bill of Rights day
Re: SOUGHT 2.0
On Dec 4, 2014, at 2:41 PM, Axb axb.li...@gmail.com wrote: On 12/04/2014 10:30 PM, Bob Proulx wrote: Axb wrote: It's been more than a month since my first SOUGHT 2.0 msg. A few have shown interest but as there hasn't been the flood of enthusiasm and stuff getting done which I hoped for so I've dropped the idea of getting a public autogenerated rule set / sa-update channel going. Good poke! And I will leave this to the list to show further enthusiasm for the project instead of simply promising time off list. Bob, It's not a poke - it's a fact. To be able to create usable rules, several times/day I need feeds to spit *at least* +150k/day. As I don't have the data…. I’d offer, but besides aggressively filtering spam, we also block several countries using the GeoIP database on our firewall (so we never even see the SMTP connections), and block a couple hundred CIDR blocks and ISPs, so it wouldn’t be a representative of what you might receive potentially.
Re: text/html rendering (was Re: ancient perl versions)
On Fri, 05 Dec 2014 12:15:10 -0500 (EST) Derek Diget derek.diget+sa-us...@wmich.edu wrote: Been a long time since I dug into MIME details and MUA display formating, but don't forget about format=flowed when it comes to Content-Type: Text/Plain and line wrapping. And/or, Content-transfer-encoding: quoted-printable with Content-Type: Text/Plain, too. That's no problem. The original text/plain part is completely preserved. Regards, David.
Re: Multiple subject headers - most blank
On 12/5/2014 11:25 AM, John Hardin wrote: FWIW: here's the rule I came up with ... seems to work adequately. header __COUNT_SUBJ Subject =~ /.*/ You might want to be a little bit more paranoid and explicitly anchor that: header __COUNT_SUBJ Subject =~ /^.*$/ I know .* is greedy and shouldn't overlap on multiple matches, but this helps make sure. I tried that originally, but it didn't end up matching. Oddly, when I put the original rule /.*/ in place, and ran a message with multiple subject lines through in debug ... I got the following relevant output: Dec 5 12:09:52.032 [2459] dbg: rules: ran header rule __COUNT_SUBJ == got hit: The Hottest Smartphones - Details Inside Dec 5 12:09:52.032 [2459] dbg: rules: ran header rule __COUNT_SUBJ == got hit: negative match Dec 5 12:09:52.032 [2459] dbg: rules: ran header rule __COUNT_SUBJ == got hit: negative match Dec 5 12:09:52.032 [2459] dbg: rules: ran header rule __COUNT_SUBJ == got hit: negative match Dec 5 12:09:52.033 [2459] dbg: rules: ran header rule __COUNT_SUBJ == got hit: The Hottest Smartphones - Details Inside Dec 5 12:09:52.033 [2459] dbg: rules: ran header rule __COUNT_SUBJ == got hit: negative match I'm assuming negative match means that the rule didn't match. The message in question has 4 subject lines, the first appears to be encoded, 2 more that are blank, the 4th one is plain text. Example: http://code.midrange.com/4c731ced97.html Not sure why the rule is being applied 6 times. david -- IBM i on Power Systems: For when you can't afford to be out of business! I'm riding a metric century (100 km / 62 miles) in the 2015 American Diabetes Association's Tour de Cure to raise money for diabetes research, education, advocacy, and awareness. You can make a tax deductible donation to my ride by visiting http://email.diabetessucks.net. My goal is $5500 but any amount is appreciated. See where I get my donations from ... visit http://email.diabetessucks.net/mapdonations.php for an interactive map (it's a geeky thing).
Re: text/html rendering (was Re: ancient perl versions)
On Fri, 5 Dec 2014 at 12:30 -0500, David F. Skoll wrote: =On Fri, 05 Dec 2014 12:15:10 -0500 (EST) =Derek Diget derek.diget+sa-us...@wmich.edu wrote: = = Been a long time since I dug into MIME details and MUA display = formating, but don't forget about format=flowed when it comes to = Content-Type: Text/Plain and line wrapping. And/or, = Content-transfer-encoding: quoted-printable with Content-Type: = Text/Plain, too. = =That's no problem. The original text/plain part is completely =preserved. Correct. I was bring those up because it comes into play with how the text/plain part is displayed with regards to line wrapping. -- *** Derek DigetOffice of Information Technology Western Michigan University - Kalamazoo Michigan USA - www.wmich.edu/ ***
Re: Multiple subject headers - most blank
On 12/5/2014 1:19 PM, Gibbs, David wrote:
On 12/5/2014 11:25 AM, John Hardin wrote:
FWIW: here's the rule I came up with ... seems to work adequately.
header __COUNT_SUBJ Subject =~ /.*/
You might want to be a little bit more paranoid and explicitly anchor
that:
header __COUNT_SUBJ Subject =~ /^.*$/
I know .* is greedy and shouldn't overlap on multiple matches, but
this helps make sure.
I tried that originally, but it didn't end up matching.
Oddly, when I put the original rule /.*/ in place, and ran a message
with multiple subject lines through in debug ... I got the following
relevant output:
Dec 5 12:09:52.032 [2459] dbg: rules: ran header rule __COUNT_SUBJ
== got hit: The Hottest Smartphones - Details Inside
Dec 5 12:09:52.032 [2459] dbg: rules: ran header rule __COUNT_SUBJ
== got hit: negative match
Dec 5 12:09:52.032 [2459] dbg: rules: ran header rule __COUNT_SUBJ
== got hit: negative match
Dec 5 12:09:52.032 [2459] dbg: rules: ran header rule __COUNT_SUBJ
== got hit: negative match
Dec 5 12:09:52.033 [2459] dbg: rules: ran header rule __COUNT_SUBJ
== got hit: The Hottest Smartphones - Details Inside
Dec 5 12:09:52.033 [2459] dbg: rules: ran header rule __COUNT_SUBJ
== got hit: negative match
I'm assuming negative match means that the rule didn't match.
The message in question has 4 subject lines, the first appears to be
encoded, 2 more that are blank, the 4th one is plain text.
Example: http://code.midrange.com/4c731ced97.html
Not sure why the rule is being applied 6 times.
david
It's likely going to have to do with (.*) accepting a zero-width match.
The regex engine effectively considers every string to have a zero-width
/thing/ between every character. The first match consumes the whole
string, leaving the cursor at the end. The next match is that zero-width
magic at the end of the text. To see this in action, compare these two
perl lines:
perl -e '$x = abc; while ($x =~ //cg) {print match\n;}' # matches
the empty spaces before 'a', and after 'a', 'b', and 'c' - 4 matches total
perl -e '$x = abc; while ($x =~ /./cg) {print match\n;}' # matches
the characters 'a', 'b', and 'c' as you would expect
Re: ancient perl versions
Charmingly polite again, eh Ted? Surely you can do better, young man.
{+_+}
On 2014-12-05 01:46, Ted Mittelstaedt wrote:
The problem is Roundcube. It does not insert soft line breaks
as per the MIME Quoted-Printable encoding. There's a lot of
MIME stuff that Roundcube doesn't do very well, it's just not a very good web
mail interface. I'm always surprised at how vehemently
people defend it.
Many email clients can be set to automatically wrap received text. Including the
one I'm using now. But I don't turn that feature on because I want to give the
SENDER of the message control over text positioning. I feel that if the sender
has laid out their email a particular way, they have a reason for it.
ASCII with a fixed font like Courier has always been the standard for email, and
you can do stuff like this with it:
-- --- \
| Network router |---| NID |---
-- --- /
Which is far, far quicker and more efficient than attaching some visio drawing
that I probably don't have a viewer for loaded on whatever system I'm using.
And I won't even get into indentation of code in Email messages.
As such, senders who are clever and careful and make use of fixed width fonts
and ASCII text can do a heck of a lot quicker communicating and more
understandable than a bunch of HTMLized stuff using a proportional spaced font
that munges drawings, and destroys indentation, and such people have a damn good
reason at times to send out text that is soft broken at specific places. So if
I turn on Word Wrap like Android does I have just succeeded in shooting myself
in the foot when I get an email from the smart people. So I assume the sender
knows what they are doing and do I don't try to second guess them by wrapping
their stuff.
If you want to send out email that looks like it's been beaten by an ugly stick
with weird looking fonts and lines that run on forever and ever, with no thought
to positioning and making it look readable, as far as I'm concerned, that's not
a reflection on me, it's a reflection on you. I'm not going to change my config
to clean up your email, particularly when your the only one doing it, no more
than I would waste time tucking in the shirt and straightening the tie and
shining the shoes of a salesguy who showed up to sell me something.
It's also not really my job to explain the concept of the blind leading the
blind and relate that to the fact that nobody else has ever yadda yadda yadda
but I'll do it anyway - it wasn't too long ago when the vast majority of people
thought the world was flat, but that merely meant that the vast majority of
people were ignorant - just like the vast majority of people who have never
brought it up to you before are just as ignorant of line wrapping. After all,
it is an esoteric subject.
Ted
On 12/4/2014 10:20 PM, Noel Butler wrote:
On 05/12/2014 14:40, Dave Pooser wrote:
On 12/4/14 10:27 PM, Nick Edwardsnick.z.edwa...@gmail.com
mailto:nick.z.edwa...@gmail.com wrote:
It's also not wrapping the text at all.
it wraps fine here
Look at the last roundcube post, the one sent at 01:06 GMT. The line of
quoted text runs 273 columns without a linewrap.
What client are you using?
roundcube - wraps
Evolution - wraps
the font size btw is identical to yours on both.
only two I use for this a/c
forwarded that message in question to my private address, and checked it
in android tablet and phone, both wrap.
since no one has ever brought this up with me before, I'm placing this
as not my problem to resolve.
Re: ancient perl versions
Ted was remarkably impolite the way he phrased it. BUT, I will say as a
practical matter microprint emails do get rather short shrift from me when
scanning through message threads. I seldom dig in here of late. But I do scan
through the messages which look interesting and sometimes offer such advice as I
can. (Usually on topics a simple Google search doesn't help with.) I'm sure my
advice would be equivalent to much other advice you might get from people whose
eyes are better than mine. And mine are far better than most of my
contemporaries and some of my former co-workers at the time. But, on the very
small chance that advice from me or someone with worse vision than even me might
help, it might be a good idea to send emails that are more readable.
I am sure I am not the only person here who would appreciate it.
Thanks
{^_^}
On 2014-12-05 07:38, Noel Butler wrote:
pffft
I see no problem, as like most developers if you cant reproduce it, then its
nothing to bother about, after all this time 2 ppl dont like a font or whatever,
your pissing up the wrong tree if you think I have a care factor about changing
things when i cant reproduce it. time to move along ...
On 05/12/2014 19:46, Ted Mittelstaedt wrote:
The problem is Roundcube. It does not insert soft line breaks
as per the MIME Quoted-Printable encoding. There's a lot of
MIME stuff that Roundcube doesn't do very well, it's just not a very good web
mail interface. I'm always surprised at how vehemently
people defend it.
Re: ancient perl versions
On 2014-12-05 07:56, Reindl Harald wrote:
Am 05.12.2014 um 16:47 schrieb Mike Grau:
On 12/05/2014 09:38 AM, Noel Butler wrote:
pffft
I see no problem, as like most developers if you cant reproduce it, then
its nothing to bother about, after all this time 2 ppl dont like a font
or whatever, your pissing up the wrong tree if you think I have a care
factor about changing things when i cant reproduce it. time to move
along ...
You're reproducing it for me ... e-mails from you have a hard-to-read
small font here also. Not from anyone else - just you
be careful or you end attacked and blacklisted as we still are because i did not
accept the personal attack and you have no right to ask anybody while playing
manner cop
http://www.gossamer-threads.com/lists/apache/dev/435100#435100
http://www.gossamer-threads.com/lists/apache/dev/435104
http://www.gossamer-threads.com/lists/apache/dev/435162#435162
Personally I'd blacklist the charming Mr. Ted Mittlestaedt, first. Until
provoked Noel has been quite polite. I do respect that.
{o.o}
Re: SOUGHT 2.0
On 2014-12-05 08:28, Axb wrote:
On 12/05/2014 05:20 PM, Kris Deugau wrote:
Axb wrote:
On 12/05/2014 01:15 AM, Ian Zimmerman wrote:
On Thu, 04 Dec 2014 22:41:13 +0100,
Axb axb.li...@gmail.com wrote:
Axb To be able to create usable rules, several times/day I need feeds
Axb to spit *at least* +150k/day. As I don't have the data
150k of what? Bytes? Emails? Tokens?
Sorry, thought this was obvious...
SOUGHT type rule generation extracts txt strings from spams so it means
+150k spams/day
It seems to work reasonably well for me with ~2-3K each ham and spam,
and even provides a handful of subrules even with ~225 spam subtype
messages. (I generate a number of sets of rules with different subtypes
of spam.)
It's probably not nearly as *effective* as it could be with larger
working sets.
Agreed.
... I use about 5-15k from the last 8 hrs (amount varies dramatically) per rule
gen run *for local* use, but that's hardly representative for global coverage.
Add LKML to your large batch of training email and I bet you get interesting
results, at best.
And one must always remember that one person's spam is another person's ham.
{o.o}
Re: ancient perl versions
On 2014-12-05 12:32, jdow wrote:
On 2014-12-05 07:56, Reindl Harald wrote:
Am 05.12.2014 um 16:47 schrieb Mike Grau:
On 12/05/2014 09:38 AM, Noel Butler wrote:
pffft
I see no problem, as like most developers if you cant reproduce it, then
its nothing to bother about, after all this time 2 ppl dont like a font
or whatever, your pissing up the wrong tree if you think I have a care
factor about changing things when i cant reproduce it. time to move
along ...
You're reproducing it for me ... e-mails from you have a hard-to-read
small font here also. Not from anyone else - just you
be careful or you end attacked and blacklisted as we still are because i did not
accept the personal attack and you have no right to ask anybody while playing
manner cop
http://www.gossamer-threads.com/lists/apache/dev/435100#435100
http://www.gossamer-threads.com/lists/apache/dev/435104
http://www.gossamer-threads.com/lists/apache/dev/435162#435162
Personally I'd blacklist the charming Mr. Ted Mittlestaedt, first. Until
provoked Noel has been quite polite. I do respect that.
s/Mittlestaedt/Mittelstaedt/The spello was unintentional. {o.o}
{o.o}
Re: ancient perl versions
John Hardin skrev den 2014-12-05 17:03: On Sat, 6 Dec 2014, Noel Butler wrote: !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN htmlbody style=3D'font-size: 10pt' ppffft/p turn html off is hard, admit its time for santa so possible write some hearts with red colors, kids garden :)
RBL and TTL
Am 26.11.2014 um 15:07 schrieb David F. Skoll: On Wed, 26 Nov 2014 14:10:04 +0100 Reindl Harald h.rei...@thelounge.net wrote: the unbound stats on our inbound MX saying the opposite How much of those are DNSBL lookups against DNSBLs with short TTLs? looks like i realize the cause of your completly different expierience * by default postscreen does RBL caching postconf -d postscreen_dnsbl_ttl postscreen_dnsbl_ttl = 1h postconf -n postscreen_dnsbl_ttl postscreen_dnsbl_ttl = 5m * unbound supports min and max TTL cache-min-ttl: 270 cache-max-ttl: 3600 well, i lowered the default 1 hour postscreen caching to 5 minutes because 1 hour feels too high given that a NXDOMAIN is also cached i was even not aware that RBL's use *that* low TTLs of a few seconds to zero, but from my expierience around 5 minutes caching are for 99% of all cases accurate enough and the idea was more to keep things fast at high load on the other hand the 3600 seconds max-ttl on the inbound MX (with it's own recursing caching nameserver forwarding some mirrored zones to a rbldnsd on 127.0.0.1:1053) is intented to get fixed DNS errors of the sending domain (PTR fixes after rejects and so on) earlier instead penalty them for 24 hours in the worst case that this helps to not exceed RBL limits is a unintentional side-effect of other optimizings and considerations while i would *highly* recommend such settings - faced days with 50 spam attempts and in that case fire up multiple dns queries to the WAN all the time is not funny :-) signature.asc Description: OpenPGP digital signature
Re: ancient perl versions
On 06/12/2014 01:56, Reindl Harald wrote: Am 05.12.2014 um 16:47 schrieb Mike Grau: On 12/05/2014 09:38 AM, Noel Butler wrote: pffft I see no problem, as like most developers if you cant reproduce it, then its nothing to bother about, after all this time 2 ppl dont like a font or whatever, your pissing up the wrong tree if you think I have a care factor about changing things when i cant reproduce it. time to move along ... You're reproducing it for me ... e-mails from you have a hard-to-read small font here also. Not from anyone else - just you be careful or you end attacked and blacklisted as we still are because i did not accept the personal attack and you have no right to ask anybody while playing manner cop http://www.gossamer-threads.com/lists/apache/dev/435100#435100 [1] http://www.gossamer-threads.com/lists/apache/dev/435104 [2] http://www.gossamer-threads.com/lists/apache/dev/435162#435162 [3] nope, only highly abusive blackmailers like you end up listed on RBL's as someone else recently posted, it doesnt take long on google to show what your true colours are and see the harsh words I spoke that you exampled in those linked threads, are truly just deserved, and if by any chance you have any mates who think I went too far, so be it, it doesnt bother me, told you that before, obviously I need to tell you again. what happens next harry is your own doing, you brought this up, remember that, so now all consequences are your own, and for the record as I said, I dont regret one single word I said to you in that post, it doesnt phase me in the least that you have retransmitted it, because those that know you, or have come across you, know you deserved it. Links: -- [1] http://www.gossamer-threads.com/lists/apache/dev/435100#435100 [2] http://www.gossamer-threads.com/lists/apache/dev/435104 [3] http://www.gossamer-threads.com/lists/apache/dev/435162#435162
Re: ancient perl versions
Ted is always impolite, but he's right that the current roundcube editor
is shocking, in many ways (but not teh way mentioned here) and a few
people have brought this up, I understand my gripes are fixed, I'll soon
know in a week or two. It is rare that I post in here anyway, I've
posted more in past couple days than most of the last 10 years combined
:)
BTW RC now tells me this is 12pt, yet looks no bigger than before.
On 06/12/2014 06:29, jdow wrote:
Ted was remarkably impolite the way he phrased it. BUT, I will say as a
practical matter microprint emails do get rather short shrift from me when
scanning through message threads. I seldom dig in here of late. But I do scan
through the messages which look interesting and sometimes offer such advice
as I can. (Usually on topics a simple Google search doesn't help with.) I'm
sure my advice would be equivalent to much other advice you might get from
people whose eyes are better than mine. And mine are far better than most of
my contemporaries and some of my former co-workers at the time. But, on the
very small chance that advice from me or someone with worse vision than even
me might help, it might be a good idea to send emails that are more readable.
I am sure I am not the only person here who would appreciate it.
Thanks
{^_^}
On 2014-12-05 07:38, Noel Butler wrote:
pffft I see no problem, as like most developers if you cant reproduce it,
then its nothing to bother about, after all this time 2 ppl dont like a font
or whatever, your pissing up the wrong tree if you think I have a care factor
about changing things when i cant reproduce it. time to move along ... On
05/12/2014 19:46, Ted Mittelstaedt wrote: The problem is Roundcube. It does
not insert soft line breaks as per the MIME Quoted-Printable encoding.
There's a lot of MIME stuff that Roundcube doesn't do very well, it's just
not a very good web mail interface. I'm always surprised at how vehemently
people defend it.
Re: ancient perl versions
Since this appears recent, I wonder if its a rc 1.0.3 issue.. again, manually setting to this 12pt, yet looks same as what people see as 10pt On 06/12/2014 02:03, John Hardin wrote: On Sat, 6 Dec 2014, Noel Butler wrote: pffft I see no problem, !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN htmlbody style=3D'font-size: 10pt' ppffft/p
Re: ancient perl versions
Hm, it renders much more readable. I normally default reading to about 12 to 14
point fonts. The 10 point was getting down to a size that some letters were
becoming ambiguous, which seriously slows down reading.
Thanks for trying.
As a side note I see that the plain text of mine you quoted is rendered as about
14. That's a not unusual mutation for MUAs it seems. There is no font size
declaration so it may be a result of some of the things I did to T'bird trying
to see if I could tame stuff. The humor this look revealed is that yuor messages
is font-size: x-large;. And about 12pt is what T'bird classifies as x-large it
appears. Most humorous.
I hope you have a good one.
{^_^}
On 2014-12-05 19:04, Noel Butler wrote:
Ted is always impolite, but he's right that the current roundcube editor
is shocking, in many ways (but not teh way mentioned here) and a few
people have brought this up, I understand my gripes are fixed, I'll soon
know in a week or two. It is rare that I post in here anyway, I've
posted more in past couple days than most of the last 10 years combined
:)
BTW RC now tells me this is 12pt, yet looks no bigger than before.
On 06/12/2014 06:29, jdow wrote:
Ted was remarkably impolite the way he phrased it. BUT, I will say as a
practical matter microprint emails do get rather short shrift from me when
scanning through message threads. I seldom dig in here of late. But I do scan
through the messages which look interesting and sometimes offer such advice as
I can. (Usually on topics a simple Google search doesn't help with.) I'm sure
my advice would be equivalent to much other advice you might get from people
whose eyes are better than mine. And mine are far better than most of my
contemporaries and some of my former co-workers at the time. But, on the very
small chance that advice from me or someone with worse vision than even me
might help, it might be a good idea to send emails that are more readable.
I am sure I am not the only person here who would appreciate it.
Thanks
{^_^}
On 2014-12-05 07:38, Noel Butler wrote:
pffft I see no problem, as like most developers if you cant reproduce it, then
its nothing to bother about, after all this time 2 ppl dont like a font or
whatever, your pissing up the wrong tree if you think I have a care factor
about changing things when i cant reproduce it. time to move along ... On
05/12/2014 19:46, Ted Mittelstaedt wrote: The problem is Roundcube. It does not
insert soft line breaks as per the MIME Quoted-Printable encoding. There's a
lot of MIME stuff that Roundcube doesn't do very well, it's just not a very
good web mail interface. I'm always surprised at how vehemently people defend
it.
Re: ancient perl versions
I'll break it down - it may be a little smaller in appearance. It's on the edge.
The prior settings worked nicer.
This one declares a body style='font-size: 10pt'. Then for each paragraph it
declares span style=3Dfont-size: small;.
It sounds like Roundfile or whatever it was (can't remember - don't want to -
web mail is an abomination - I am THAT old) and T'bird combined have some really
peculiar rendering notions.
{o.o}
On 2014-12-05 19:07, Noel Butler wrote:
Since this appears recent, I wonder if its a rc 1.0.3 issue..
again, manually setting to this 12pt, yet looks same as what people see
as 10pt
On 06/12/2014 02:03, John Hardin wrote:
On Sat, 6 Dec 2014, Noel Butler wrote:
pffft I see no problem,
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
htmlbody style=3D'font-size: 10pt'
ppffft/p
Re: ancient perl versions
No problems Jo, I might give its svn version a go, but as its the weekend I'm about to jet off for a couple days, will try it monday, and 12pt as large? LOL, maybe thats why RC defaults to 10pt as average :) Cheers On 06/12/2014 13:21, jdow wrote: Hm, it renders much more readable. I normally default reading to about 12 to 14 point fonts. The 10 point was getting down to a size that some letters were becoming ambiguous, which seriously slows down reading. Thanks for trying. As a side note I see that the plain text of mine you quoted is rendered as about 14. That's a not unusual mutation for MUAs it seems. There is no font size declaration so it may be a result of some of the things I did to T'bird trying to see if I could tame stuff. The humor this look revealed is that yuor messages is font-size: x-large;. And about 12pt is what T'bird classifies as x-large it appears. Most humorous. I hope you have a good one.
Re: ancient perl versions
Yeah, this is a few nibblies with this current version, how it made it
past beta I'll never know
On 06/12/2014 13:28, jdow wrote:
I'll break it down - it may be a little smaller in appearance. It's on the
edge. The prior settings worked nicer.
This one declares a body style='font-size: 10pt'. Then for each paragraph it
declares span style=3Dfont-size: small;.
It sounds like Roundfile or whatever it was (can't remember - don't want to -
web mail is an abomination - I am THAT old) and T'bird combined have some
really peculiar rendering notions.
{o.o}
On 2014-12-05 19:07, Noel Butler wrote:
Since this appears recent, I wonder if its a rc 1.0.3 issue.. again, manually
setting to this 12pt, yet looks same as what people see as 10pt On 06/12/2014
02:03, John Hardin wrote: On Sat, 6 Dec 2014, Noel Butler wrote: pffft I see
no problem, !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
htmlbody style=3D'font-size: 10pt' ppffft/p
