Has there been a recent uptick in crap sent to the list or is it just me?
Is there anything that we can do to filter these messages with junk links?
-AK
It's not just you.
I added this to my postfix header_checks:
/^Subject:.*\bFw: new message/ REJECT No more new messages
please
All. Weekend. Long.
I wanted someone to say something before I did. I thought I was the only one.
Kirill Klimakhin
Principal Consultant
Kirill.Klimakhin@corebts.com
www.corebts.com
I see it too, there are some 517 messages in my spam folder "New message"
Most of them get blocked, but a small fraction are still making it into my inbox
The spam is real.
You can tune your own spamassassin-installation by adding these lines to local.cf:
#Custom Rule for SPAMCOP
header SUBJECT_FW_NEWMESSAGE Subject =~ /(Fw: new message)/
describe SUBJECT_FW_NEWMESSAGE subject fw new message
score SUBJECT_FW_NEWMESSAGE 10.0
I caught hundreds of these in my spam folder.
Gunther
Filtering *@jdlabs.fr did the trick for me.
Of course, now I have to write a much more complex filter to hide all the
complaining about NANOG spam 
Ian Smith
Hi,
I added this two lines to our postfix header checks:
/mike@sentex\.net/ DISCARD
/jdenoy@jdlabs\.fr/ DISCARD
Worked very well:
# grep -i discard /var/log/mail.log | grep -iE "@jdlabs|@sentex" | wc -l
408
Best regards
Jürgen Jaritsch
Head of Network & Infrastructure
ANEXIA Internetdienstleistungs GmbH
Telefon: +43-5-0556-300
Telefax: +43-5-0556-500
E-Mail: JJaritsch@anexia-it.com
Web: http://www.anexia-it.com
Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt
Geschäftsführer: Alexander Windbichler
Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601
I think there might be more emails discussing the spam, than the actual spam itself.
But it is originating all from different IP addresses. Who knows if this
is an attack to get *@jdlabs.fr blocked from NANOG and is just getting
its goal accomplished.
not even close to more discussing than from the original spam. Not even
close.
Not even in the same order of magnitude, I don't think.
Hi,
not even close to more discussing than from the original spam. Not even
close.
data volume wise, the discussion of spam is easily beating the volume of spam
(which some people had issue with) as the SPAM emails were very small with just a
URL - the discusions about it is now spread into around 6 threads with many pages of text
in some messages.
alan
<snip>
But it is originating all from different IP addresses. Who knows if this
is an attack to get *@jdlabs.fr blocked from NANOG and is just getting
its goal accomplished.
This is the part that's been bugging me. Doesn't the NANOG server
implement SPF checking on inbound list mail? jdlabs.fr doesn't appear to
have an SPF record published. It seems to me that these messages should
have been dropped during the connection.
Ian Smith
Don't know, but it doesn't matter: SPF has zero anti-spam value.
(I know. I've studied this in ridiculous detail using a very large
corpus of spam/nonspam messages over a very long period of time.)
There are much better methods available.
---rsk
If it does (which I don't know), it will probably check the SPF record
of the delivering mailserver, which was not *.jdlabs.fr as far as I can
see from the mailheaders.
Jutta Zalud
But that's not how SPF works. In SPF, the domain of the envelope header
sender address is checked against that domain's sender policy. Since
jdlabs.fr has no policy specified, a strict SPF policy at the NANOG server
would have prevented this small issue.
As for the utility of SPF, well. It's not comprehensive, no one I know
would say that it is. But it's a bit of a stretch to say that has zero
value. It would have prevented this latest bit of fun, which seems to have
people upset, so there's *some* value.
-Ian
No, it's not a stretch at all. It's a statistical reality. And a single
isolated case does not alter that.
You're welcome to set up your own network of spamtraps and mailboxes,
ingest a sizable corpus of messages, and analyze it. If you do so,
and if you take care to ensure that the composition of that traffic
is appropriate (that is, not skewed by network, domain, ASN, TLD,
etc.), and you accumulate samples over a period of many years,
you'll find the same thing.
This wasn't always true, incidentally. In the early days of SPF,
it did have some value, because -- by far -- the most prolific
early adopters of SPF were spammers.
---rsk
I'm not making any argument about the relation of SPF compliance to message
quality or spam/ham ratio. You are no doubt correct that at this point in
the game SPF doesn't matter with respect to message quality in a larger
context, because these days messages that are not SPF compliant will simply
never arrive, and therefore aren't sent.
I'm saying that SPF helps prevent envelope header forgery, which is what it
was designed to do. The fact that NANOG isn't checking SPF (and it isn't,
I tested) was exploited and resulted in a lot of spam to the list. This
wasn't caught by receiving servers (like Gmail's, for example) because they
checked mail.nanog.org against the nanog.org spf record, which checked out.
You can argue that envelope header forgery is irrelevant, and that corner
cases don't matter. But I think this latest incident provides a good
counterexample that it does matter. And it's easy to fix, so why not fix
it?
-Ian