I mentioned this problem at the last round-table session, but didn't get
a solution, so I thought I'd post it here, just in case anyone has any
suggestions to offer.
I'm still seeing a whole bunch of false positives in SpamAssassin, since
an update was installed in mid-September on a CentOS 5.7 system, for a
rule called DATE_IN_FUTURE_96_Q, which is only supposed to be triggered
when the "Date:" header has a date that is 4 days to 4 month ahead of
the date in the "Received" header that …
[View More]has the _smallest_ difference in
date.
Here are the headers from the latest e-mail I've received with this
false-positive. (I've stripped out irrelevant headers, for the sake of
clarity and simplicity.)
From topfivestories(a)messagent.itworldcanada.com Mon Nov 14 07:50:13 2011
Received: from mail.messagent.itworldcanada.com
(mail.messagent.itworldcanada.com [207.112.10.80])
by palladium.cs.umanitoba.ca (8.13.8/8.13.8) with SMTP id
pAEDoAxV028594
for <gedetil(a)cs.umanitoba.ca>; Mon, 14 Nov 2011 07:50:12 -0600
Date: Mon, 14 Nov 2011 08:50:13 -0500
X-Spam-Status: No, score=-0.3 required=5.0
tests=BAYES_00,DATE_IN_FUTURE_96_Q,
HTML_MESSAGE,RP_MATCHES_RCVD autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
palladium.cs.umanitoba.ca
Note that I'm calling spamd via the spamass-milter on a system running
sendmail. Note also, that in the above example, the only "Received"
header was the one generated by my own server. (I've had other false
positives, however, with multiple "Received" headers, all of which were
within seconds of the time in the "Date" header.)
Any ideas?
--
Gilbert E. Detillieux E-mail: <gedetil(a)muug.mb.ca>
Manitoba UNIX User Group Web: http://www.muug.mb.ca/
PO Box 130 St-Boniface Phone: (204)474-8161
Winnipeg MB CANADA R2H 3B4 Fax: (204)474-7609
[View Less]
Does anyone have a spare ATX power supply? Mine seems to have a problem.
Specifically, when I run the CPUID Hardware Monitor, it reports these
voltages:
[image: Inline image 1]
The numbers for -12V concern me. :-) The columns are Current/Min/Max,
respectively. So if you have a power supply that's taking up space that
you'd like to reclaim, please let me know and bring it to the next MUUG
meeting.
As it happens, I'll be bringing some valuable (I hope) hardware items to
the meeting as free …
[View More]giveaways. I sure hope there are some takers!
Kevin
P.S. If the image inserted above doesn't show up due to filtering en route,
the -12V reading is around -6.21V. I'm using the system as we speak, so I
guess the -12V line doesn't do much that I regularly rely on, though I have
experienced some system oddness lately which may well be explained by this.
[View Less]
A follow-up question of sorts -- I've been using gmail as my email
provider of choice for years -- so I've become accustomed to their
service. I have a "spam" folder on my mailboxes and they filter and
route the emails into that folder if they detect it *may* be spam. I
regularly go through that folder and pull out the odd false-positives
that occur (yes, they occur all the time).
For those of you who have local mail via one of the big providers
(shaw/mts/etc) - if you use their email …
[View More]addresses (@shaw or @mts, /etc)
do they provide some kind of spam filtering service? If so, what do
they do with the spam that they detect? Do they file it somewhere, or
just let it through to your mailbox or delete it or???
Is there any consistency between providers or do they all do their own
thing?
Thanks.
Dan.
[View Less]
(I`m sending this to sksp, AW & a few wpg technology groups; please forward
to anyone who may be interested)
Due to the "bad capacitor plague", a number of electronic devices produced
during the early to late 2000s have become unstable and unusable. In many
cases, a few minutes and dollars spent to replace the capacitors will
restore them to functionality. Come to Skullspace at 7pm on October 17th to
learn the basics and try your hand at the process.
If possible, let me know of your …
[View More]attendance in advance - CStanners(a)gmail.com
.
[View Less]
Further to our discussion on Tuesday night:
As a wonderful local example, I’ve just discovered that with postfix, enforcing valid HELO hostnames (which really isn’t all that stringent a check!) prevents the Winnipeg Free Press’ website from emailing me. It seems registering on the website causes the registration-confirmation email to be sent from “clickability.com” (aka Limelight’s “Dynamic Site Platform”). OK, fine. They even have reverse DNS set up correctly. But their outbound MX …
[View More]host identified itself as “la-mailout1.clickability.com”. No such A record exists, so postfix immediately rejects the message at the HELO stage.
FWIW, the host connecting to me is “dv-mailout1.clickability.com”, which correctly resolves forward and reverse.
For anyone who’s interested, my Postfix main.cf reads, in part:
smtpd_helo_restrictions =
permit_inet_interfaces,
permit_mynetworks,
permit_sasl_authenticated,
check_helo_access hash:/etc/postfix/client_access,
reject_invalid_helo_hostname,
reject_non_fqdn_helo_hostname,
reject_unknown_helo_hostname,
reject_unauth_pipelining,
reject_rhsbl_helo zen.spamhaus.org
but adding:
dv-mailout1.clickability.com OK
la-mailout1.clickability.com OK
208.80.58.240 OK
to /etc/postfix/client_access (and remembering to run postmap on it) eventually convinces Postfix to let this message in. (But typically not immediately, which I still don’t understand. Ideas?) Only one of those lines should be necessary, but I’ve never figured out which one :-).
-Adam Thompson
athompso(a)athompso.net
[View Less]
So, after our long(ish) discussion on mail/postfix/spamassasin/etc last
night, I thought I'd run through a few things.
...OK -- I checked out a few things -- one of them to confirm I was
*not* running an open relay ...
Based upon my own checks and one I found on the net, it's not an open
relay ...
if you're interested, from the machine you want to test, goto:
telnet rt.njabl.org 2500
that will initiate a number of checks - takes about a minute or so ..
check your mail logs and the logs on …
[View More]the telnet screen for output.
Dan.
[View Less]
I mentioned this at last nights meeting. This is just a follow-up. Not
necessarily a MUUG thing but a Linux thing none the less.
At next months MWCS meeting on November 6'th (one week before the MUUG
meeting) I will be giving a demo of a working LTSP system. I will spend
10 minutes describing the process I used to get it working and the rest
of the evening will be an exploration of the system. If there is an
expert reading this post who would like to contribute, feel free to drop
by and …
[View More]take over after I do my bit.
The address for the meeting will be 3390 Portage Avenue on the South
side (between Westwood and Caviller - I think that's the general area).
Land marks are the Safeway and McCardboard on the North side of Portage
as well as the Princess Auto and Giant Tiger a block or so to the East
on the South side. The time is 7:00 - 9:00 sharp. Parking is in the rear
of the church. Enter through the back door and head down stairs.
A bit about what to expect from the MWCS. The group is a generic
computer club. We don't care what sort of computer people run. The
ability level of the club is somewhat less than that of the MUUG. It is
also substantially smaller than the MUUG with resources to match. We
don't even have an internet connection available to us. The MWCS web
page can be found at http://mwcs.mb.ca.
For follow-up... Questions about the LTSP can (and logically should) be
handled through the mailing list. Questions about the MWCS will be
handled privately through e-mail.
Later
Mike
[View Less]
IIRC, stderr doesn't buffer, stdout does. Both must block eventually once they hit the maximum buffer size the kernel and/or libc impose.
Buffering != blocking.
-Adam
Robert Keizer <robert(a)keizer.ca> wrote:
>On 12-10-10 10:33 AM, Gilbert E. Detillieux wrote:
>> On 2012-10-10 09:50, Robert Keizer wrote:
>>> I have a production service that prints some debug to stdout. I could
>>> make it print to stderr, but it really doesn't matter in this case.
>>
&…
[View More]gt;> Are you sure it doesn't matter? Read on...
>>
>>> I want to have some hope of if something goes wrong figuring out what
>>> did.
>>> Log files aren't really an option so I ran it in screen. Yes yes I could
>>> have made it network log to somewhere else, but again, not really an
>>> viable option in this case. Works great as the program dies and the
>>> output stops, leaving the last debug messages in the buffer of screen.
>>
>> One of the classic C/UNIX lessons about stdout vs stderr is that the C
>> library buffers stdout by default but not stderr, exactly for the
>> reason that you want error messages to be flushed out right away,
>> leaving nothing in the buffer. This is particularly important if the
>> program dies in a way that prevents the usual exit processing, such as
>> flushing buffers and closing file I/O.
>>
>> So, issues with "screen" aside, you probably should either send your
>> debug output to stderr, or set your stdout to unbuffered mode while
>> debugging (or both).
>>
>
>Interesting!
>
>Thought I'd test out stdout vs stderr just to see if this was in fact
>the case. It's not - stderr and stdout have the same effect in this case.
>
>Below is a script the listens for incoming data on a given port (
>example is 1337 ). When data is received it writes to either stdout or
>stderr and then sends data on to another port ( in this case 1338 ).
>This script also fills up the screen buffer by a simple loop ( tested
>filling with both stderr and stdout ).
>
>Using telnet to feed the script data, and nc ( nc -lk 1338 ) to listen
>on port 1338 for the output, one can test to confirm.
>
>
>net = require "net"
>server = net.createServer ( c ) ->
> c.setEncoding "utf8"
> c.on "data", ( data ) ->
> _c = net.createConnection 1338, ( ) ->
> process.stderr.write "Data: " + data + "\n"
> _c.write data
> _c.end( )
>
>server.listen 1337, "127.0.0.1"
>loops = ( ) ->
> process.stderr.write "Loopies: " + Date( ) + "\n"
> setTimeout loops, 100
>loops( )
>
>Screenshot is attached - it shows this script in the top left running in
>screen, with copy mode enabled. Right of it is the telnet session
>feeding it, and on the bottom left is the nc or "output". Note that the
>last two inputs did not make it to the output. Ergo, unless I'm totally
>an idiot in my implementation: This is blocking on stderr as well.
>
>Thoughts? Because now I'm officially annoyed that this blocks on stderr
>as well!
>
>Rob
>
>
>_______________________________________________
>Roundtable mailing list
>Roundtable(a)muug.mb.ca
>http://www.muug.mb.ca/mailman/listinfo/roundtable
[View Less]