Mail Defender Lite?

[DaveB]

So...

What is this, and why can't I turn it off, or manipulate it's settings?

I've just discovered, (some weeks after migration) one club members mail
list I need to see, isn't getting through, but others are.

Went to the web based mail management portal and I can see this
"Service", but can't disable it, or manipulate it's settings...

C&W strike again?

Anyone know how to turn it off?

Dave B.

[Tony]

DaveB <g8...@uko2.co.uk> wrote on Tue, 9 Oct 2012 at 17:00:11:
>So...
>
>What is this, and why can't I turn it off, or manipulate it's settings?

<http://help.demon.net/help-articles/demon-mail-migration-frequently-aske
d-questions/#whatmdflite>

>I've just discovered, (some weeks after migration) one club members mail
>list I need to see, isn't getting through, but others are.

Is that club member receiving bounce messages when he tries to email
you? If so, has he reported the false positive as per
<http://help.demon.net/help-articles/demon-mail-migration-frequently-aske
d-questions/#reportfalsepositives>? Apparently, that may help. If he's
not receiving bounce messages, I'd be puzzled.

>Went to the web based mail management portal and I can see this
>"Service", but can't disable it, or manipulate it's settings...
>
>C&W strike again?
>
>Anyone know how to turn it off?

It seems that it can be made to happen if you ask nicely in the Demon
Forum <http://forum.demon.net/>.

73,
--
Tony

[DaveB]

In article <d5V2symR...@hotair.localhost.invalid>,
tonyh1...@hotair.demon.co.uk says...

>
>
> It seems that it can be made to happen if you ask nicely in the Demon
> Forum <http://forum.demon.net/>.
>
> 73,

Looking (and searching) that forum, all I see are hundreds (if not
1000's) of complaints about SPAM mostly, and very little what I'd call
"tehnical" help, even in the "Technical Support" list, that seems mainly
populated by complaints and waffle.

Dave.

[DaveB]

In article <d5V2symR...@hotair.localhost.invalid>,
tonyh1...@hotair.demon.co.uk says...
>

> DaveB <g8...@uko2.co.uk> wrote on Tue, 9 Oct 2012 at 17:00:11:
> >So...
> >
> >What is this, and why can't I turn it off, or manipulate it's settings?
>
> <http://help.demon.net/help-articles/demon-mail-migration-frequently-aske
> d-questions/#whatmdflite>
>
> >I've just discovered, (some weeks after migration) one club members mail
> >list I need to see, isn't getting through, but others are.
>
> Is that club member receiving bounce messages when he tries to email
> you? If so, has he reported the false positive as per
> <http://help.demon.net/help-articles/demon-mail-migration-frequently-aske
> d-questions/#reportfalsepositives>? Apparently, that may help. If he's
> not receiving bounce messages, I'd be puzzled.

No, no warnings or rejection messages are sent back. It's the list
mail that's not getting through to ME!

>
> >Went to the web based mail management portal and I can see this
> >"Service", but can't disable it, or manipulate it's settings...
> >
> >C&W strike again?
> >
> >Anyone know how to turn it off?
>
> It seems that it can be made to happen if you ask nicely in the Demon
> Forum <http://forum.demon.net/>.

Realy? In the Help file you linked above, this appears...

[Quote]
Can I opt out of spam filtering?

All customers are automatically assigned a copy of MailDefender Lite
which does not allow customers to Opt out.
[UnQuote]

Arghhhhh!


>
> 73,

..

Dave.

[Tony]

DaveB <g8...@uko2.co.uk> wrote on Wed, 10 Oct 2012 at 13:49:58:
>In article <d5V2symR...@hotair.localhost.invalid>,
>tonyh1...@hotair.demon.co.uk says...
>>
>> DaveB <g8...@uko2.co.uk> wrote on Tue, 9 Oct 2012 at 17:00:11:
>> >So...
>> >
>> >What is this, and why can't I turn it off, or manipulate it's settings?
>>
>> <http://help.demon.net/help-articles/demon-mail-migration-frequently-aske
>> d-questions/#whatmdflite>
>>
>> >I've just discovered, (some weeks after migration) one club members mail
>> >list I need to see, isn't getting through, but others are.
>>
>> Is that club member receiving bounce messages when he tries to email
>> you? If so, has he reported the false positive as per
>> <http://help.demon.net/help-articles/demon-mail-migration-frequently-aske
>> d-questions/#reportfalsepositives>? Apparently, that may help. If he's
>> not receiving bounce messages, I'd be puzzled.
>
>No, no warnings or rejection messages are sent back. It's the list
>mail that's not getting through to ME!

That does make it difficult to diagnose the cause :( For example, it
may be SPF-checking that is causing the rejections, rather than Mail
Defender.

>> >Went to the web based mail management portal and I can see this
>> >"Service", but can't disable it, or manipulate it's settings...
>> >
>> >C&W strike again?
>> >
>> >Anyone know how to turn it off?
>>
>> It seems that it can be made to happen if you ask nicely in the Demon
>> Forum <http://forum.demon.net/>.
>
>Realy? In the Help file you linked above, this appears...
>
>[Quote]
>Can I opt out of spam filtering?
>
>All customers are automatically assigned a copy of MailDefender Lite
>which does not allow customers to Opt out.
>[UnQuote]
>
>Arghhhhh!

Indeed, but the FAQs don't tell the full story, and have not been
updated to reflect changes.

My observation is that Demon are slowly responding to customer concerns
about false positives from both SPF-rejections and spam filtering.
Several customers have SPF checking bypassed (including me) and I have
seen examples where a customer has spam filtering disabled. Of course,
disabling either runs the risk of more spam :(

I suggest you contact support by one means or another. new...@demon.net
or the forum are the only ones I've used so far regarding the email
migration or its effects.

--
Tony

[John Hall]

In article <MPG.2adf7f4e...@aioe.org>,

Apparently Demon have had second thoughts, as one or two people have
indeed been told in the forum within the last couple of weeks that if
they wish they can opt out of the spam checking.
--
John Hall

"The beatings will continue until morale improves."
Attributed to the Commander of Japan's Submarine Forces in WW2

[Jim O'Reilly]

>
>Apparently Demon have had second thoughts, as one or two people have
>indeed been told in the forum within the last couple of weeks that if
>they wish they can opt out of the spam checking.

Spam filter is not working today.Got loads of Booking.com today through
Mail Defender Lite:(
--
Jim O'Reilly

[Martin Brown]

Sadly it looks like the quality of the spam forging has improved in a
way that temporarily defeats the latest Demon antispam measures :(

Anyone good at interpreting headers care to comment on one of my ewoks
many recent hotel bookings? Looks to me like it originates in India, but
I can't make head nor tail of the X-Spam-Relays-Untrusted: fields.

Certain mailboxes have "#" substitutions for actual text.

---start forged header ---

From - Wed Oct 10 17:34:32 2012
X-Account-Key: account3
X-UIDL: 1143
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
X-Mozilla-Keys:

Received: from smtp.demon.co.uk (91.221.168.47) by HVUT02.thus.corp
(192.168.70.42) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed,
10 Oct
2012 17:24:04 +0100
Received: from mdfmta006.tbr.inty.net (unknown [127.0.0.1]) by
mdfmta006.tbr.inty.net (Postfix) with ESMTP id 11F1A3B406C for
<##########@nezumi.demon.co.uk>; Wed, 10 Oct 2012 17:26:01 +0100 (BST)
Received: from mdfmta006.tbr.inty.net (unknown [127.0.0.1]) by
mdfmta006.tbr.inty.net (Postfix) with ESMTP id E47CB3B406D for
<##########@nezumi.demon.co.uk>; Wed, 10 Oct 2012 17:26:00 +0100 (BST)
Received: from mdfmta006.tbr.inty.net (unknown [127.0.0.1]) by
mdfmta006.tbr.inty.net (Postfix) with ESMTP id 9708A3B4067 for
<#ew...@nezumi.demon.co.uk>; Wed, 10 Oct 2012 17:26:00 +0100 (BST)
Received-SPF: neutral (mdfmta006.tbr.inty.net: 122.176.241.220 is
neither permitted nor denied by domain of booking.com)
client-ip=122.176.241.220; envelope-from=overtur...@booking.com;
helo=ABTS-North-Dynamic-220.241.176.122.airtelbroadband.in;
Received: from ABTS-North-Dynamic-220.241.176.122.airtelbroadband.in
(unknown
[122.176.241.220]) by mdfmta006.tbr.inty.net (Postfix) with ESMTP for
<#ew...@nezumi.demon.co.uk>; Wed, 10 Oct 2012 17:25:58 +0100 (BST)
X-Spam-Relays-Untrusted: [ ip=208.117.50.32 rdns=o1.sg.booking.com
helo=o1.sg.booking.com by=rcdn-inbound-i.cisco.com ident= envfrom=
intl=0 id= auth= msa=0 ] [ ip=10.9.180.5 rdns=
helo=mail-out1.booking.com by=mi14 ident= envfrom= intl=0
id=2aac47b12.7d02.a32d5b auth= msa=0 ] [ ip=10.147.206.183
rdns=mc01nwscron-01.prod.lhr1.booking.com helo=localhost.localdomain
by=mtx-05.prod.lhr1.booking.com ident=
envfrom=customer...@booking.com intl=0 id=1BZGyz-0507Gp-MV auth=
msa=0 ]
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sg.booking.com;
h=from:to :subject:date:mime-version:content-type
:content-transfer-encoding:message-id; s=smtpapi; bh=dvpK9xregK4
iz9BuUaBlIRAtFYw=; b=KySFCg64/pRqDkmd990JTT1IRvUfNmrwTz9i2RTawWb
X1+0XUMPEfRSS4ZUOGMDaI8N8Whk6wEXmKkqDT01jtILf19D+qNB6GvLlasOTXy+
nEpzPQZVxuW90SLUEzrXJjHz7Lkr+K0N3qZSc3773A4hnewZW4Ljw/oPyeJ39lIA =
DomainKey-Signature: a=rsa-sha1; c=nofws; d=booking.com; h=from:to
:subject:date:mime-version:content-type
:content-transfer-encoding:message-id; q=dns; s=smtpapi; b=QdySN
r4K3lzv5s1qjNallBcN5opBbFG8B8gPEg7iFy/tzQHyuvRYzdE6h88j0wd2ImB9R
lAAwyHiKSxXtmuvPjxXFXJ7HQ1OWLZsPAcMVIDetSA7QkguOKFTjzUBBNUAcAdcd
EtNhpPiAc1oZFGQfmtlLrC8osZwHiJ4OsJ6M7U=
Received: by 10.41.149.113 with SMTP id a09-08.3159.4FB477984 Wed, 10
Oct 2012
21:55:57 +0530
Received: from mc02csapp-02.corp.lhr1.booking.com (unknown [[10.146.174.14])
by mi14 (SG) with ESMTP id 4ac47b57.7f02.a72d5b for
<customer...@booking.com>; Wed, 10 Oct 2012 21:55:57 +0530
Received: from mc01nwscron-01.prod.lhr1.booking.com ([10.147.206.183]:56512
helo=localhost.localdomain) by mc02csapp-02.corp.lhr1.booking.com with
esmtp
(Exim 4.76) (envelope-from <customer...@booking.com>) id
1BZGyz-0507Gp-MV for boo...@sendgrid.net; Wed, 10 Oct 2012 21:55:57 +0530
From: Booking.com <customer...@my.booking.com>
To: <#ew...@nezumi.demon.co.uk>
Subject: Booking Confirmation 26280634
X-Booking-Segment: cc1=us; language=en; extra_label=_499base;
home_ufi=0; has_profile=0; user_id=0; last_booked_ufi=0
Date: Wed, 10 Oct 2012 21:55:57 +0530
Message-ID: <V0FVGuz-...@mtx-04.prod.lhr1.booking.com>
Content-Type: multipart/mixed; boundary="----=a__sdwqlyyf_14_91_34"
X-MDF-HostID: 23
X-MDF-HostID: 23
Return-Path: overtur...@booking.com
X-MS-Exchange-Organization-AuthSource: HVUT02.thus.corp
X-MS-Exchange-Organization-AuthAs: Anonymous
MIME-Version: 1.0

------=a__sdwqlyyf_14_91_34
Content-Type: multipart/alternative; boundary="----=_sdwqlyyf_14_91_34"

------=_sdwqlyyf_14_91_34
Content-Type: text/plain; charset="windows-1250"
Content-Transfer-Encoding: quoted-printable

---end---

Is there a good reason why booking.com do not SPF softfail this dross?

--
Regards,
Martin Brown

[Neil Jackson]

On 10/10/2012 20:30, Martin Brown wrote:

> Sadly it looks like the quality of the spam forging has improved in a
> way that temporarily defeats the latest Demon antispam measures :(

It wouldn't take much 'improvements'. Demon's antispam measures are
largely (imho) not as good as they used to be, since the move from
Cloudmark to Mail Defender Lite (more of this later).

>
> Anyone good at interpreting headers care to comment on one of my ewoks
> many recent hotel bookings? Looks to me like it originates in India, but
> I can't make head nor tail of the X-Spam-Relays-Untrusted: fields.

Yup - it originates from:

ABTS-North-Dynamic-220.241.176.122.airtelbroadband.in

aka: IP 122.176.241.220

Everything below that are lies; X-headers have no defined meaning within
the SMTP spec anyway (and can thus be ignored, from the POV of
delivery-routing, though they may - in a 'real' message, contain useful
side-information). The 'received' headers are what *should* be the
truth, but examine them closely, and they do not link, one to the other,
after the Indian line.

It's a simple (oldschool) attempt to misguide you into thinking that
this DID come from booking.com, in the hope that you won't know how to
read trace-headers or just jump to the bottom and assume the middle
section is all genuine.

The duff headers (which even include domainkeys/DKIM signatures) have
presumably just been ripped from a genuine message from bookings.com,
but I've not verified every single IP on the list to make sure. There
are evident oddities - 'for customer-service@' for example; I almost
wonder if this is hacked from a read-receipt or an inbound message to
booking.com which has been bounced and dissected in order to make some
valid-looking lines. The 10.x.x.x 'received' which comes after then
Indian 'received', which doesn't record any inbound IP is a nice touch -
because it *looks* on the face of it, like the ball was dropped by
booking.com's own internal mail relays, one of which doesn't record the
connecting IP - but that is likely to be balls. It's where the trail
breaks, if you take it from the top down.



<snip>

>
> Is there a good reason why booking.com do not SPF softfail this dross?
>

Booking.com's SPF catch-all record in the DNS is set to '?all' - meaning
(to downstream MTAs that are looking-up) 'you decide'. It fulfils
Booking.com's perceived need to vouch for their own IPs, but it leaves
them safe in the event that any of their thousands of real users use
forwarding-addresses (which will be hundreds). If they used hardfail,
these would be bounced - if they used softfail, they'd end up as spam.

IMHO, it reflects booking.com's moderate contempt for SPF records, which
I share. They're basically saying 'here are our IPs, in case you're
twattish enough to try blocking us if we have NO SPF record at all, but
we're not going to denounce messages that aren't from these IPs...
because they could be genuine or fake; you decide."

I'm slightly more curious as to why the Domainkeys/DKIM signatures
weren't checked (or if they were, how come they passed inspection),
because they are supposed to be more robust than SPF, and attempt to
verify a particular MESSAGE having come from a valid source, rather than
bothering will all this sender-IP generic balls. Maybe Demon aren't
checking the DK stuff? Certainly looks like booking.com are implementing
it their end (look in the DNS for TXT records at
smtpapi._domainkey.sg.booking.com and you'll find some public keys to
use with the ones in the messages. I've not gone so far as to check that
they decode vs the keys in this message, but if they do *that* is
probably where the innovation is coming in to play. Everything else
looks pretty stock, but a DK signature 'steal' is new to me.

Off to look for DK exploits! :-)

TTFN
--
Neil

[Martin Brown]

On 12/10/2012 18:36, Neil Jackson wrote:
> On 10/10/2012 20:30, Martin Brown wrote:
>
>> Sadly it looks like the quality of the spam forging has improved in a
>> way that temporarily defeats the latest Demon antispam measures :(
>
> It wouldn't take much 'improvements'. Demon's antispam measures are
> largely (imho) not as good as they used to be, since the move from
> Cloudmark to Mail Defender Lite (more of this later).

Possibly. ALthough the instantaneous improvement in SNR after migration
was initially 1% of the spam rate I was seeing on the old system.

>> Anyone good at interpreting headers care to comment on one of my ewoks
>> many recent hotel bookings? Looks to me like it originates in India, but
>> I can't make head nor tail of the X-Spam-Relays-Untrusted: fields.
>
> Yup - it originates from:
>
> ABTS-North-Dynamic-220.241.176.122.airtelbroadband.in
>
> aka: IP 122.176.241.220
>
> Everything below that are lies; X-headers have no defined meaning within

Thanks. I was hoping I hadn't completely lost my touch. But these
new-fangled things are getting harder and harder to make sense of.

> The duff headers (which even include domainkeys/DKIM signatures) have
> presumably just been ripped from a genuine message from bookings.com,
> but I've not verified every single IP on the list to make sure. There
> are evident oddities - 'for customer-service@' for example; I almost
> wonder if this is hacked from a read-receipt or an inbound message to
> booking.com which has been bounced and dissected in order to make some
> valid-looking lines. The 10.x.x.x 'received' which comes after then
> Indian 'received', which doesn't record any inbound IP is a nice touch -
> because it *looks* on the face of it, like the ball was dropped by
> booking.com's own internal mail relays, one of which doesn't record the
> connecting IP - but that is likely to be balls. It's where the trail
> breaks, if you take it from the top down.

Thanks for the detaile dexplanation.

> <snip>
>>
>> Is there a good reason why booking.com do not SPF softfail this dross?
>>
>
> Booking.com's SPF catch-all record in the DNS is set to '?all' - meaning
> (to downstream MTAs that are looking-up) 'you decide'. It fulfils
> Booking.com's perceived need to vouch for their own IPs, but it leaves
> them safe in the event that any of their thousands of real users use
> forwarding-addresses (which will be hundreds). If they used hardfail,
> these would be bounced - if they used softfail, they'd end up as spam.

Ah. Yes. It would have unfortunate side effects there.

> IMHO, it reflects booking.com's moderate contempt for SPF records, which
> I share. They're basically saying 'here are our IPs, in case you're
> twattish enough to try blocking us if we have NO SPF record at all, but
> we're not going to denounce messages that aren't from these IPs...
> because they could be genuine or fake; you decide."
>
> I'm slightly more curious as to why the Domainkeys/DKIM signatures
> weren't checked (or if they were, how come they passed inspection),
> because they are supposed to be more robust than SPF, and attempt to
> verify a particular MESSAGE having come from a valid source, rather than
> bothering will all this sender-IP generic balls. Maybe Demon aren't
> checking the DK stuff? Certainly looks like booking.com are implementing
> it their end (look in the DNS for TXT records at
> smtpapi._domainkey.sg.booking.com and you'll find some public keys to
> use with the ones in the messages. I've not gone so far as to check that
> they decode vs the keys in this message, but if they do *that* is
> probably where the innovation is coming in to play. Everything else
> looks pretty stock, but a DK signature 'steal' is new to me.
>
> Off to look for DK exploits! :-)

Be interested to know what you find.
>
> TTFN

Thanks for your analysis.

--
Regards,
Martin Brown

[Neil Jackson]

On 15/10/2012 09:54, Martin Brown wrote:
> On 12/10/2012 18:36, Neil Jackson wrote:
>> On 10/10/2012 20:30, Martin Brown wrote:
>>
>>> Sadly it looks like the quality of the spam forging has improved in a
>>> way that temporarily defeats the latest Demon antispam measures :(
>>
>> It wouldn't take much 'improvements'. Demon's antispam measures are
>> largely (imho) not as good as they used to be, since the move from
>> Cloudmark to Mail Defender Lite (more of this later).
>
> Possibly. ALthough the instantaneous improvement in SNR after migration
> was initially 1% of the spam rate I was seeing on the old system.

Bear in mind that over recent days, Cloudmark seems to have been 'badly
fed' (or not maintained, or something unusual), and latterly, its
hitrate has not been nearly so good as it was of old. I have an
(entirely speculative) feeling that it was 'put out to grass' some time
before Demon decided to go for this new M$-based, outsourced system.

That's one reason why the new system looks 'better'.

Another reason is that the new system mercilessly uses SPF hardfail;
which was not part of Cloudmark's remit, and thus comparison is flawed.

One could say that Cloudmark's understanding of spam was based on
content (heuristic analysis of the words in the message) and public-vote
(people tagging messages as spam), whereas the new system may or may not
do either of those things - and if it did, we can't measure how well it
does it - because it does a third thing: SPF-rejection - which as we
well know, is currently rejecting a fair proportion of GOOD mail.

My observations lately have been that spam has gone UP since the
migration - but so far (touches wood) I have not been subjected to any
of the massive joe-job attempts of old, nor a singular, targeted
mass-mail just to my addresses. I also run SpamAssassin on a gateway
server in-between, so this may have a bearing on matters too. Hard to be
sure.

Certainly, the introducing of SPF-rejection has made a big difference,
but imho, I'm not convinced it's a good one. It's my belief that if
SPF-rejection were removed from the equation, and the new system was
compared with Cloudmark on a like-for-like basis, Cloudmark would win.
Put another way, if you added SPF-rejection to Cloudmark, it would
probably beat what we've got now (but of course, would result in just as
many false postives, due to the flawed way in which SPF works).

>> Off to look for DK exploits! :-)
>
> Be interested to know what you find.

A sick wife and two sick kids (and the signs of sniffles myself) has
thus far prevented much in the way of investigation so far! I'm still
struggling to work out how this DK spoofing was done (and whether Demon
even checks DK-sigs). My current theory is that the spammers somehow
manage to send and receive a message of some kind to/from bookers.com
itself, in order to obtain a time-limited-but-valid DK sig which they
strip out and apply to another message, altering the criteria that it is
set to validate-for (i.e. not the message body, but some of the headers
instead). I'm not even sure this would really work, but it's all I can
come up with without putting it on the slab and getting really forensic
with it - which will have to wait for now, until the family is all well
again!

TTFN
--
Neil

[Martin Brown]

On 15/10/2012 10:28, Neil Jackson wrote:
> On 15/10/2012 09:54, Martin Brown wrote:
>> On 12/10/2012 18:36, Neil Jackson wrote:

>>> Off to look for DK exploits! :-)
>>
>> Be interested to know what you find.
>
> A sick wife and two sick kids (and the signs of sniffles myself) has
> thus far prevented much in the way of investigation so far! I'm still

Oh dear. Hope they are all soon better.

Looks like it is DHL's turn this morning to be spam-du-demi-jour.

The new stuff evolves extremely fast. I am probably going to block large
chunks of the subcontinent IP address space if this persists.
eg anything from airtelbroadband.in for starters

--
Regards,
Martin Brown

[Neil Jackson]

On 15/10/2012 11:41, Martin Brown wrote:
> On 15/10/2012 10:28, Neil Jackson wrote:
>> On 15/10/2012 09:54, Martin Brown wrote:
>>> On 12/10/2012 18:36, Neil Jackson wrote:
>
>>>> Off to look for DK exploits! :-)
>>>
>>> Be interested to know what you find.
>>
>> A sick wife and two sick kids (and the signs of sniffles myself) has
>> thus far prevented much in the way of investigation so far! I'm still
>
> Oh dear. Hope they are all soon better.

Thanks

>
> Looks like it is DHL's turn this morning to be spam-du-demi-jour.
>
> The new stuff evolves extremely fast. I am probably going to block large
> chunks of the subcontinent IP address space if this persists.
> eg anything from airtelbroadband.in for starters

The daft thing is, there *should* be no need. It should be done FOR you,
by an effective anti-spam strategy.

F'rinstance, that last email which we dissected... I forgot at the time
to check something blindling obvious... blacklists. Scope this out;

http://ip.robtex.com/122.176.241.220.html#blacklists

The IP is the injection point we identified last week - and you can see
from the Robtex round-up, that it is blacker than a black cat in a coal
cellar at midnight with the lights off and no moon.

What in all of Bill Gates's trouser-dom was Demon even doing, accepting
that email in the first place? Beggar SPF, to hell with DKIM sigs... the
fact that it was coming from an IP address with a rep about as wholesome
as Dr Crippen's *should* have been enough to make it about-face and tell
it to 'go away and play'.

But it didn't. Instead it accepted it, and duly sent it on to you, after
a good few minutes spend running it round in timewasting loops 'testing'
it and 'filing' it, and gawd-knows-what (prolly taking a copy for the
Govt-required black-box, too). Pointless. Cloudmark (or simple blacklist
lookups at SMTP-delivery-attempt time) would've nuked that one from orbit.

As far as I'm concerned (in terms of how my local deliveries get
processed once they arrive at my end of the pipe), one positive
nasty-hit from zen.spamhaus.org is usually enough to determine it
hostile and add a nice big dollop of 'spam-juice' to the message. Enough
to instantly ensure it gets filed into my spam-bucket. If the message
content itself then turns out to be 'spammy' (heuristically), then
that'll add more, and if it crosses a threshold, it'll simply be nuked
without me ever having seen it.

My point in all this is, why aren't Demon catching these? They are
*childs-play*.

In fairness, I suppose it could be argued that the offending IP in
question maybe didn't hit the blacklists until *after* that email was
sent, but I very much doubt it. That whole Class C is in the doghouse as
far as Spamrats is concerned, and Spamhaus have it marked as a policy
block - i.e. the ISP concerned refutes all emails originating from those
IPs (presumably those customers are allowed only to send email out via a
smarthost).

With regards to your new DHL one, would you mind plonking up the SMTP
headers (minus your personal info), so I can have a quick peruse
sometime? I'm lucky enough not to have received one today!

I'd like to see if this is another instance of 'should've been caught'.

Cheers
--
Neil

[Martin Brown]

On 15/10/2012 14:15, Neil Jackson wrote:
> On 15/10/2012 11:41, Martin Brown wrote:

>> Looks like it is DHL's turn this morning to be spam-du-demi-jour.
>>
>> The new stuff evolves extremely fast. I am probably going to block large
>> chunks of the subcontinent IP address space if this persists.
>> eg anything from airtelbroadband.in for starters
>
> The daft thing is, there *should* be no need. It should be done FOR you,
> by an effective anti-spam strategy.
>
> F'rinstance, that last email which we dissected... I forgot at the time
> to check something blindling obvious... blacklists. Scope this out;
>
> http://ip.robtex.com/122.176.241.220.html#blacklists
>
> The IP is the injection point we identified last week - and you can see
> from the Robtex round-up, that it is blacker than a black cat in a coal
> cellar at midnight with the lights off and no moon.

So it would seem. What are Demon playing at? They use an SPF logic that
rejects genuine redirected customer emails and accept garbage from some
of the darkest places on the internet. It makes no sense at all!

> My point in all this is, why aren't Demon catching these? They are
> *childs-play*.

Agreed.
I hadn't thought to look carefully. I just assumed it was a typical ISP
and a bunch of penniless users with no AV software on broadband.

> In fairness, I suppose it could be argued that the offending IP in
> question maybe didn't hit the blacklists until *after* that email was
> sent, but I very much doubt it. That whole Class C is in the doghouse as
> far as Spamrats is concerned, and Spamhaus have it marked as a policy
> block - i.e. the ISP concerned refutes all emails originating from those
> IPs (presumably those customers are allowed only to send email out via a
> smarthost).
>
> With regards to your new DHL one, would you mind plonking up the SMTP
> headers (minus your personal info), so I can have a quick peruse
> sometime? I'm lucky enough not to have received one today!
>
> I'd like to see if this is another instance of 'should've been caught'.

I suspect it should. In the meantime they have morphed into Facebook
spams about lunchtime so I include one of each. Every one that gets
through seems to be from a different dark place (about a dozen today)

Here is a DHL one from India again.

From - Mon Oct 15 10:03:18 2012
X-Account-Key: account3
X-UIDL: 1350

X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
X-Mozilla-Keys:

Received: from smtp.demon.co.uk (91.221.168.47) by HVUT02.thus.corp

(192.168.70.42) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon,
15 Oct
2012 10:01:28 +0100

Received: from mdfmta006.tbr.inty.net (unknown [127.0.0.1]) by

mdfmta006.tbr.inty.net (Postfix) with ESMTP id BFEB23B406C for
<##########@nezumi.demon.co.uk>; Mon, 15 Oct 2012 10:02:36 +0100 (BST)

Received: from mdfmta006.tbr.inty.net (unknown [127.0.0.1]) by

mdfmta006.tbr.inty.net (Postfix) with ESMTP id 919733B406A for
<##########@nezumi.demon.co.uk>; Mon, 15 Oct 2012 10:02:36 +0100 (BST)

Received: from mdfmta006.tbr.inty.net (unknown [127.0.0.1]) by

mdfmta006.tbr.inty.net (Postfix) with ESMTP id CEAD93B4069 for
<#c1...@nezumi.demon.co.uk>; Mon, 15 Oct 2012 10:02:30 +0100 (BST)
Received-SPF: softfail (mdfmta006.tbr.inty.net: transitioning domain of
dhl.com does not designate 59.181.142.139 as permitted sender)
client-ip=59.181.142.139; envelope-from=unver...@dhl.com;
helo=static-mum-59.181.142.139.mtnl.net.in;
Received: from static-mum-59.181.142.139.mtnl.net.in (unknown
[59.181.142.139]) by mdfmta006.tbr.inty.net (Postfix) with ESMTP for
<#c1...@nezumi.demon.co.uk>; Mon, 15 Oct 2012 10:02:02 +0100 (BST)
X-Spam-Relays-Untrusted: [ ip=199.40.206.33 rdns= helo=gateway2e.dhl.com
by=cm-mr13 ident= envfrom= intl=0 id=23/77-03268-86BBBFE4 auth= msa=0 ]
[ ip=199.40.20.207 rdns= helo=mykulws2393.kul-dc.dhl.com
by=gateway2e.dhl.com ident= envfrom= intl=0 id= auth= msa=0 ] [
ip=23.252.17.99 rdns= helo=MYKULWS2399.kul-dc.dhl.com
by=MYKULWS2395.kul-dc.dhl.com ident= envfrom= intl=0 id=14.1.339.1 auth=
msa=0 ]
Received: from mykulws2393.kul-dc.dhl.com ([199.40.20.207]) by
gateway2e.dhl.com with ESMTP/TLS/AES128-SHA; Mon, 15 Oct 2012 14:32:01
+0530
Received: from MYKULWS2362.kul-dc.dhl.com (169.254.5.235) by
MYKULWS2393.kul-dc.dhl.com (199.40.20.207) with Microsoft SMTP Server (TLS)
id 14.1.339.6; Mon, 15 Oct 2012 14:32:01 +0530
From: DHL Express International <no-r...@dhl.com>
To: <#c1...@nezumi.demon.co.uk>
Subject: Processing complete successfully
Date: Mon, 15 Oct 2012 14:32:01 +0530
Message-ID: <XVBC70ST7Y22LUTV...@kul-dc.dhl.com>
Content-Type: multipart/mixed; boundary="----=mpoint__eslbqmhz_08_13_87"
X-MDF-HostID: 23
X-MDF-HostID: 23
Return-Path: unver...@dhl.com

X-MS-Exchange-Organization-AuthSource: HVUT02.thus.corp
X-MS-Exchange-Organization-AuthAs: Anonymous
MIME-Version: 1.0

------=mpoint__eslbqmhz_08_13_87
Content-Type: multipart/alternative; boundary="----=_eslbqmhz_08_13_87"

------=_eslbqmhz_08_13_87
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable

DHL Express Tracking Notification: Mon, 15 Oct 2012 14:32:01 +0530=
Custom Reference: 9776640-EDL8NEKPGCW =
Tracking Number: 2947678629 Pickup Date: Mon, 15 Oct 2012=
14:32:01 +0530 Service: AIR/GROUND Pieces: 2 =

-----end of fake DHL spam headers ---
-----start Facebook fake headers ----

From - Mon Oct 15 11:53:34 2012
X-Account-Key: account3
X-UIDL: 1357

X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
X-Mozilla-Keys:

Received: from smtp.demon.co.uk (91.221.168.47) by HVUT01.thus.corp
(192.168.70.41) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon,
15 Oct
2012 11:49:19 +0100

Received: from mdfmta006.tbr.inty.net (unknown [127.0.0.1]) by

mdfmta006.tbr.inty.net (Postfix) with ESMTP id 1151B3B40BF for
<##########@nezumi.demon.co.uk>; Mon, 15 Oct 2012 11:50:28 +0100 (BST)

Received: from mdfmta006.tbr.inty.net (unknown [127.0.0.1]) by

mdfmta006.tbr.inty.net (Postfix) with ESMTP id 37E543B40B1 for
<##########@nezumi.demon.co.uk>; Mon, 15 Oct 2012 11:50:24 +0100 (BST)

Received: from mdfmta006.tbr.inty.net (unknown [127.0.0.1]) by

mdfmta006.tbr.inty.net (Postfix) with ESMTP id 063413B40CE for
<#car...@nezumi.demon.co.uk>; Mon, 15 Oct 2012 11:50:24 +0100 (BST)
Received-SPF: softfail (mdfmta006.tbr.inty.net: transitioning domain of
dhl.com does not designate 1.217.23.245 as permitted sender)
client-ip=1.217.23.245; envelope-from=subverti...@dhl.com;
helo=[1.217.23.245];
Received: from [1.217.23.245] (unknown [1.217.23.245]) by

mdfmta006.tbr.inty.net (Postfix) with ESMTP for

<#car...@nezumi.demon.co.uk>;
Mon, 15 Oct 2012 11:50:20 +0100 (BST)
Received: from outmail012.snc7.facebook.com (HELO mx-out.facebook.com)
([69.171.232.146]) with ESMTP; Mon, 15 Oct 2012 19:50:20 +0900
Received: from [10.64.120.50] ([10.64.120.50:34638]) by
smout016.snc7.facebook.com (envelope-from
<notification...@facebookmail.com>) (ecelerity 2.2.2.45
r(34222M))
with ECSTREAM id 40/AC-03990-B59ED7F4; Mon, 15 Oct 2012 19:50:20 +0900
X-Facebook: from zuckmail ([MTI3LjAuMC4x]) by graph.facebook.com with
HTTP (ZuckMail);
Date: Mon, 15 Oct 2012 19:50:20 +0900
To: <#car...@nezumi.demon.co.uk>
From: Facebook <notification...@facebookmail.com>
Reply-To: noreply <nor...@facebookmail.com>
Subject: Your friend added a new photo with you to the album
Message-ID: <81M5KF5FJ5X6YXVP...@graph.facebook.com>
X-Mailer: ZuckMail [version 1.00]
Errors-To: notification...@facebookmail.com
X-Facebook-Notify: close_friend_activity;
mailid=W22812346AG32463ROLLZYUEF36PG35Y
X-FACEBOOK-PRIORITY: 0
Content-Type: multipart/mixed; boundary="----=a__xlrbmzwnow_37_53_07"
X-MDF-HostID: 23
X-MDF-HostID: 23
Return-Path: subverti...@dhl.com
X-MS-Exchange-Organization-AuthSource: HVUT01.thus.corp
X-MS-Exchange-Organization-AuthAs: Anonymous
MIME-Version: 1.0

------=a__xlrbmzwnow_37_53_07
Content-Type: multipart/alternative; boundary="----=_xlrbmzwnow_37_53_07"

------=_xlrbmzwnow_37_53_07
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Facebook facebook
Greetings,
One of Your Friends added a new photo with you to the album.

You are receiving this email because you've been liste=
d as a close friend.

---end-- spam headers

Second one looks like it is from Korea.
Another very dark place full of counterfeit and malware riddled software
where back when I had to visit I would spend the first day delousing
their office computers before I could make any progress.

Interesting that its return address is subvert...@dhl.com

The one good thing is that this bulk UCE spam has provided me with the
push needed to reimplement my own local blocking rules and tested them
extensively. Every big black cloud has a silver lining of sorts ;-)

--
Regards,
Martin Brown

[Tony]

Neil Jackson <ja...@techno.demon.co.uk.invalid> wrote on Mon, 15 Oct
2012 at 10:28:04:

According to
<http://help.demon.net/help-articles/demon-mail-migration-frequently-aske
d-questions/#whatmdflite>, the new system's MailDefender uses Cloudmark
as well.
--
Tony

[Neil Jackson]

On 15/10/2012 15:35, Martin Brown wrote:
> On 15/10/2012 14:15, Neil Jackson wrote:
>> On 15/10/2012 11:41, Martin Brown wrote:
>

[snip]

>> http://ip.robtex.com/122.176.241.220.html#blacklists
>>
>> The IP is the injection point we identified last week - and you can see
>> from the Robtex round-up, that it is blacker than a black cat in a coal
>> cellar at midnight with the lights off and no moon.
>
> So it would seem. What are Demon playing at? They use an SPF logic that
> rejects genuine redirected customer emails and accept garbage from some
> of the darkest places on the internet. It makes no sense at all!

This is my big gripe with their new system.

I've been trying to find the right analogy and can't, really - but it's
close to having an immigration policy which completely ignores all boats
coming from known Foriegn-Office-advised 'illegal' countries and ports
(whose port authorities don't even have phones, let alone answer
enquiries by UK border control), and yet it spends altogether far too
much time on ringing France and Spain and other 'known and nearby' ports
and countries unnecessarily for every arriving boat.

And then going nuts when a ferry arrives from France by way of Jersey,
where it stops off to pick up hydroponic tomatoes and holidaymakers and
bring them back to Blighty. Everyone arriving in the UK on that boat
gets deported, because when we called them, the French authorities said
"it left Le Havre, monsieur - we don't know nussink about it
overnighting in le Jersey! Zat is outside our contrerl." (apols to M.
Clouseau).

The Jersey authorities meanwhile, are completely ignored, never phoned,
not checked. They would only be considered at all if they had written
the boat's travel documents in Swahili - which is not cost-effective for
them to learn, of course.

The captain of the vessel gently bangs his head against the helm, and
sobs, saying "This happens *every* time now! Why didn't I just stick to
driving buses in Peckham?"

Meanwhile, fourteen boats from North Korea have snuck in unfettered
(whilst playing the North Korean national Anthem loudly on the P.A, with
the crew shouting "We from Dee Haitch Hell, honest!"), and have brought
in counterfeit tomatoes that have made everyone Kim Jong Ill.

Like I said, the analogy isn't perfect (by any means) - but it's the
best I can do at short notice! :)

The upshot is, Mail Defender Lite is evidently 'Lite' in the sense of
'lightweight and useless', rather than simply absent of 'extra' or
advanced functionality. RBL lookups are not 'advanced' - they're
Antispam 101. If MDL is not doing IP blacklist lookups of any kind, and
is relying SOLELY on SPF, then that's NOT an effective solution. It's
just another kludge, and will cause more kludge-related problems.

>
>> My point in all this is, why aren't Demon catching these? They are
>> *childs-play*.
>
> Agreed.

[snip]

> Here is a DHL one from India again.
>
> From - Mon Oct 15 10:03:18 2012
> X-Account-Key: account3
> X-UIDL: 1350
> X-Mozilla-Status: 0001
> X-Mozilla-Status2: 00000000
> X-Mozilla-Keys:
> Received: from smtp.demon.co.uk (91.221.168.47) by HVUT02.thus.corp
> (192.168.70.42) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon,
> 15 Oct
> 2012 10:01:28 +0100
> Received: from mdfmta006.tbr.inty.net (unknown [127.0.0.1]) by
> mdfmta006.tbr.inty.net (Postfix) with ESMTP id BFEB23B406C for
> <##########@nezumi.demon.co.uk>; Mon, 15 Oct 2012 10:02:36 +0100 (BST)
> Received: from mdfmta006.tbr.inty.net (unknown [127.0.0.1]) by
> mdfmta006.tbr.inty.net (Postfix) with ESMTP id 919733B406A for
> <##########@nezumi.demon.co.uk>; Mon, 15 Oct 2012 10:02:36 +0100 (BST)
> Received: from mdfmta006.tbr.inty.net (unknown [127.0.0.1]) by
> mdfmta006.tbr.inty.net (Postfix) with ESMTP id CEAD93B4069 for
> <#c1...@nezumi.demon.co.uk>; Mon, 15 Oct 2012 10:02:30 +0100 (BST)
> Received-SPF: softfail (mdfmta006.tbr.inty.net: transitioning domain of
> dhl.com does not designate 59.181.142.139 as permitted sender)
> client-ip=59.181.142.139; envelope-from=unver...@dhl.com;
> helo=static-mum-59.181.142.139.mtnl.net.in;

Interestingly, this one actually popped up an SPF warning (albeit in
'softfail' mode, because DHL understandably aren't daft enough to
implement 'hardfail' for a notification service which may well end up
being forwarded legitimately).

Demon have been given a clue, right there. DHL says '59.181.142.139' is
"not one of ours", and to treat it with kid gloves.

You'd think Demon would use that signal to at least ensure this
untrusted-by-DHL IP was double-checked against a blacklist, as part of
the 'heightened spam checks' that should be a response to a softfail
(assuming they're not applied to everything automatically).

> Received: from static-mum-59.181.142.139.mtnl.net.in (unknown
> [59.181.142.139]) by mdfmta006.tbr.inty.net (Postfix) with ESMTP
> for
> <#c1...@nezumi.demon.co.uk>; Mon, 15 Oct 2012 10:02:02 +0100 (BST)

Bear in mind, at the time that mdfmta006.tbr.inty.net received this from
59.181.142.139 and wrote this line, it was within its grasp to quickly
DNS-lookup that IP against any number of RBLs, and it would've come back
blacker than Satan's backside. They could've marked the message right
there as 'dodgy', and been greater than 70%* right, imho. If they'd
looked it up on two RBLs and got confirmed hits, they could've opted to
terminate the SMTP connection right there, saving themselves and the
downstream world (you, DHL and their inty/POP infrastructure) a ton of
resource-wastage and possibly further implications (malware removal
costs, etc).

Nope; they'll ignore the connecting-IP totally, and instead fanny about
DNSing against the SMTP Envelope-From domain to see if there are SPF
records for this IP, all of which results may be non-existent,
inconclusive or just plain wrong, just as often as they turn out to be
right and useful.

It's nuts. It's like we've forgotten everything we ever knew about
spam-fighting (I've been doing it since the days of the Lumber Cartel in
the early 90s - TinLC, and all that). Instead, we're chasing rainbows in
the garden of the delusioned, and Microsoft is leading the way to the
happy hill, where the pot of gold isn't (at least, not for us).

The rest of the email headers below are cobblers. The 'lies' start
immediately after this line - though if Demon had been doing its job,
arguably, it should've/could've checked each and every IP address found
in each and every 'received' header below - but they wouldn't/shouldn't
'undo' the damage caused by the failed lookup of the connecting IP
59.181.142.139 - when they were shaking the spammer by the hand warmly,
and suggesting "we'll just ask DHL if they know you, Mr H4xx0r S.
Kiddy,... oh, they say they're not sure, well, never mind... Come on in
anyway, take a seat and dictate your message... we'll pass it right on..."

> X-Spam-Relays-Untrusted: [ ip=199.40.206.33 rdns=
> helo=gateway2e.dhl.com by=cm-mr13 ident= envfrom= intl=0
> id=23/77-03268-86BBBFE4 auth= msa=0 ] [ ip=199.40.20.207 rdns=
> helo=mykulws2393.kul-dc.dhl.com by=gateway2e.dhl.com ident= envfrom=
> intl=0 id= auth= msa=0 ] [ ip=23.252.17.99 rdns=
> helo=MYKULWS2399.kul-dc.dhl.com by=MYKULWS2395.kul-dc.dhl.com ident=
> envfrom= intl=0 id=14.1.339.1 auth= msa=0 ]
> Received: from mykulws2393.kul-dc.dhl.com ([199.40.20.207]) by
> gateway2e.dhl.com with ESMTP/TLS/AES128-SHA; Mon, 15 Oct 2012
> 14:32:01 +0530
> Received: from MYKULWS2362.kul-dc.dhl.com (169.254.5.235) by
> MYKULWS2393.kul-dc.dhl.com (199.40.20.207) with Microsoft SMTP
> Server (TLS)
> id 14.1.339.6; Mon, 15 Oct 2012 14:32:01 +0530
> From: DHL Express International <no-r...@dhl.com>

[snip]

Similar game with the Facebook fake:

A non-attempt to check IP in RBLs, followed by an almost pointless
effort to look it up against DHL, who by their own admission know
nothing about them and can't judge.

Stupid, stupid, stupid, stupid.

> -----start Facebook fake headers ----

[snip]

> Received-SPF: softfail (mdfmta006.tbr.inty.net: transitioning domain of
> dhl.com does not designate 1.217.23.245 as permitted sender)
> client-ip=1.217.23.245; envelope-from=subverti...@dhl.com;
> helo=[1.217.23.245];
> Received: from [1.217.23.245] (unknown [1.217.23.245]) by
> mdfmta006.tbr.inty.net (Postfix) with ESMTP for
> <#car...@nezumi.demon.co.uk>;

And below this line are the pre-injected 'lie' headers, which bear no
resemblance to the sender-domain, incidentally (though I am not
proposing Demon or anyone should necessary 'induce' logic on that basis,
but it is laughable when we look back at it and see it in this context):

> Mon, 15 Oct 2012 11:50:20 +0100 (BST)
> Received: from outmail012.snc7.facebook.com (HELO mx-out.facebook.com)
> ([69.171.232.146]) with ESMTP; Mon, 15 Oct 2012 19:50:20 +0900
> Received: from [10.64.120.50] ([10.64.120.50:34638]) by
> smout016.snc7.facebook.com (envelope-from
> <notification...@facebookmail.com>) (ecelerity 2.2.2.45
> r(34222M))
> with ECSTREAM id 40/AC-03990-B59ED7F4; Mon, 15 Oct 2012 19:50:20 +0900
> X-Facebook: from zuckmail ([MTI3LjAuMC4x]) by graph.facebook.com with
> HTTP (ZuckMail);
> Date: Mon, 15 Oct 2012 19:50:20 +0900
> To: <#car...@nezumi.demon.co.uk>
> From: Facebook <notification...@facebookmail.com>

>

> Second one looks like it is from Korea.

Agreed

> Another very dark place full of counterfeit and malware riddled software
> where back when I had to visit I would spend the first day delousing
> their office computers before I could make any progress.
>
> Interesting that its return address is subvert...@dhl.com

I *think* that's just coincidence, rather than any deliberate spammer
joke/implied threat. Probably tomorrow's will be
'randomw...@dhl.com'. But it is interesting, I agree!

>
> The one good thing is that this bulk UCE spam has provided me with the
> push needed to reimplement my own local blocking rules and tested them
> extensively. Every big black cloud has a silver lining of sorts ;-)

I agree that it's good to be on our toes - but that's not enough of a
silver-lining for me. I expect DEMON to be on their toes; clearly
they've fallen on their ar5es instead, and are implementing this
'anti-spam' like total noobs. Either they're desperate to save on costs
and damn the problems it causes for customers (especially if they're
'invisible' ones which don't come to light immediately or leave any
paper-trail), or they've employed the under-twelves to do their
outsourced anti-spam, and they're still learning it first-time out. What
happened to the great resource of Demon's amassed knowledge? Have they
really, really ALL left the company now? Do I have to physically erect
statues in honour of the heroic works of Richard Clayton and Clive
Feather in order for Demon to realise what they've lost?

IMHO, the ratio of black cloud to silver lining is about 9million to 1*. :(

Moving on...

Sadly, none of those 'fresh meat' spams contained DomainKeys signatures,
so I'm not any closer to working out whether that's been exploited.

I am rapidly forming the opinon, though, that Demon probably doesn't
look them up anyway, so they're neither helping nor harming the spam's
passage to us. However, I'm sure in *some* places - the ones that do DK
lookups - they'd stop the spam dead in its tracks; so either the
spammers are stupid - (which is a given, and was the first law of the
Lumber Cartel (tinlc) anyway), or they're evidence that DK has been
'gotten-around' and is being used in a way that *aids* the spammers (as
is the case with some SPF-based attacks these days too). I can't imagine
that whatever system they use for 'pruning' legitimate-looking headers
from real emails in order to stuff them into the 'lie' section of their
fakes (and potentially re-date/time them to match), would grab the
DK-sigs if they knew them to be potentially-harmful. They *are* that
stupid, but it would seem unlikely they'd do this for long. I shall have
to keep watch...

Cheers



(* bearing in mind, of course, that precisely 98.345345% of all
statistics are made up on the spot. :) )
--
Neil

[Neil Jackson]

On 15/10/2012 15:40, Tony wrote:

> According to
> <http://help.demon.net/help-articles/demon-mail-migration-frequently-aske
> d-questions/#whatmdflite>, the new system's MailDefender uses Cloudmark
> as well.

Well spotted, Tony. Thanks.

Hmm - if that's true (and we have no reason to think Demon would lie),
something else has to be different, then.

Given the observations made since my original post, I have a feeling it
boils down to simple Realtime-Blacklist Lookups, and the fact that Demon
don't *appear* to be doing any, or the lists they're using aren't
good/fresh ones.

Whether RBL lookups form part of Cloudmark's 'out of the box' strategy,
I really don't know - but if it was being done before, it's evidently
not being done as well now, in the new Mail Defender Lite paradigm.
IMHO, of course.

[John Hall]

In article <J4afs.412068$pO4....@fx17.am4>,
Neil Jackson <ja...@techno.demon.co.uk.invalid> writes:
<big snip>

>I agree that it's good to be on our toes - but that's not enough of a
>silver-lining for me. I expect DEMON to be on their toes; clearly
>they've fallen on their ar5es instead, and are implementing this
>'anti-spam' like total noobs. Either they're desperate to save on
>costs and damn the problems it causes for customers (especially if
>they're 'invisible' ones which don't come to light immediately or
>leave any paper-trail), or they've employed the under-twelves to
>do their outsourced anti-spam, and they're still learning it first-time
>out.

Probably a bit of both. (Though the cynic in me does wonder if Mail
Defender Lite is deliberately not very good so that people will fork out
to have the full Mail Defender.)

> What happened to the great resource of Demon's amassed
>knowledge? Have they really, really ALL left the company now?

Judging by the farewells we saw on various demon.* newsgroups from those
who had a presence there, it seems all too likely. When Thus took over
Demon, at least they had the sense to keep most of the experienced Demon
people, but C&W apparently thought that they knew better.

>Do I have to physically erect statues in honour of the heroic works
>of Richard Clayton and Clive Feather in order for Demon to realise
>what they've lost?

:)

I wonder how many of Demon's current employees would even recognise
their names.

[Tony]

Neil Jackson <ja...@techno.demon.co.uk.invalid> wrote on Tue, 16 Oct
2012 at 10:55:52:

A browse of the Cloudmark website suggests that it depends on whether
Demon/intY have included "Cloudmark Sender Intelligence" or not. See p10
of the "Fixed Network Security Solutions Guide" at
<http://www.cloudmark.com/releases/docs/solutionguides/Fixed%20Network%20
Security%20Solutions%20Guide_July%202012.pdf>. It's still marked
"Proprietary & Confidential", so burn after reading :)
--
Tony

[Martin Brown]

On 16/10/2012 10:49, Neil Jackson wrote:

> Sadly, none of those 'fresh meat' spams contained DomainKeys signatures,
> so I'm not any closer to working out whether that's been exploited.

Hi Neil,

I think what happens is the hostile causes itself to get sent an
acknowledgement email from customer service at where ever and then
steals the resulting headers to bolt onto the bottom of its header
pattern and tweaks dates/times accordingly for reuse in spam.

So far only booking.com and skype has DKIM and they are identical byte
for byte for the same source domain days apart and from multiple bots.

SPF softfail are from DHL, Facebook, RoyalMail, Skype

Todays have now morphed into
BT Business Direct Order with a stolen dabs.com header under it.

>
> I am rapidly forming the opinon, though, that Demon probably doesn't
> look them up anyway, so they're neither helping nor harming the spam's
> passage to us. However, I'm sure in *some* places - the ones that do DK
> lookups - they'd stop the spam dead in its tracks; so either the
> spammers are stupid - (which is a given, and was the first law of the
> Lumber Cartel (tinlc) anyway), or they're evidence that DK has been
> 'gotten-around' and is being used in a way that *aids* the spammers (as
> is the case with some SPF-based attacks these days too). I can't imagine
> that whatever system they use for 'pruning' legitimate-looking headers
> from real emails in order to stuff them into the 'lie' section of their
> fakes (and potentially re-date/time them to match), would grab the
> DK-sigs if they knew them to be potentially-harmful. They *are* that
> stupid, but it would seem unlikely they'd do this for long. I shall have
> to keep watch...
>
> Cheers
>
> (* bearing in mind, of course, that precisely 98.345345% of all
> statistics are made up on the spot. :) )

The only saving grace is that computers and broadband are now fast
enough to cope with the huge volume of dross. I can't help feeling that
cauterising dodgy parts of the internet might be the only solution.

We are due another Swenfest - such events are roughly once per decade.

--
Regards,
Martin Brown

[Martin Brown]

On 16/10/2012 12:01, Martin Brown wrote:
> On 16/10/2012 10:49, Neil Jackson wrote:
>
>> Sadly, none of those 'fresh meat' spams contained DomainKeys signatures,
>> so I'm not any closer to working out whether that's been exploited.
>
>

> So far only booking.com and skype has DKIM and they are identical byte
> for byte for the same source domain days apart and from multiple bots.
>
> SPF softfail are from DHL, Facebook, RoyalMail, Skype
>
> Todays have now morphed into
> BT Business Direct Order with a stolen dabs.com header under it.

Here is another fresh meat DKIM and softfail from Paypal.
The forged source seems to be rapidly varying on an hourly basis.

---starts---

From - Tue Oct 16 12:13:17 2012
X-Account-Key: account3
X-UIDL: 1381

X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
X-Mozilla-Keys:

Received: from smtp.demon.co.uk (91.221.168.42) by HVUT01.thus.corp
(192.168.70.41) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue,
16 Oct
2012 12:11:30 +0100
Received: from mdfmta001.tbr.inty.net (unknown [127.0.0.1]) by
mdfmta001.tbr.inty.net (Postfix) with ESMTP id 876CF6A4075 for
<##########@nezumi.demon.co.uk>; Tue, 16 Oct 2012 12:12:41 +0100 (BST)

Received: from mdfmta006.tbr.inty.net (unknown [127.0.0.1]) by

mdfmta006.tbr.inty.net (Postfix) with ESMTP id 494F93B40A0 for
<##########@nezumi.demon.co.uk>; Tue, 16 Oct 2012 12:12:39 +0100 (BST)

Received: from mdfmta006.tbr.inty.net (unknown [127.0.0.1]) by

mdfmta006.tbr.inty.net (Postfix) with ESMTP id 0A3933B409A for
<#ew...@nezumi.demon.co.uk>; Tue, 16 Oct 2012 12:12:39 +0100 (BST)

Received-SPF: softfail (mdfmta006.tbr.inty.net: transitioning domain of

paypal.com does not designate 146.255.13.179 as permitted sender)
client-ip=146.255.13.179; envelope-from=stuffin...@paypal.com;
helo=[146.255.13.179];
Received: from [146.255.13.179] (unknown [146.255.13.179]) by

mdfmta006.tbr.inty.net (Postfix) with ESMTP for

<#ew...@nezumi.demon.co.uk>;
Tue, 16 Oct 2012 12:12:38 +0100 (BST)
Delivery-date: Tue, 16 Oct 2012 11:12:31 +0000
Received: from mx3.slc.paypal.com ([173.0.84.228]:39390
helo=mx0.slc.paypal.com) by server15.verygoodserver.com with esmtp
(Exim 4.77) (envelope-from <pay...@paypal.com>) id
1SyYdz-0003XU-BP; Tue, 16 Oct 2012 11:12:31 +0000
DomainKey-Signature: q=dns; a=rsa-sha1; c=nofws; s=dkim;
d=paypal.com;
h=DKIM-Signature:Received:Date:Message-Id:Subject:X-MaxCode-Template:To:From:X-Email-Type-Id:X-XPT-XSL-Name:Content-Type:MIME-Version;

b=GynGqSh4fPzvKQ2T5bjITNCfkZNZ1GKbcnuI8JZKHjB5s2EaiyumUpu/bgH9fVSN
n/dmS9Lb+Q/4MpRL99BCXn3iHn9c9djNLR/1sc424GAJyD9w0QSnI68AUNop9wbV
cwtz5Id2Z7qLEGq7CQn08c/px2GYc7Uhzo2KRYhQ7ys=
DKIM-Signature: v=1; a=rsa-sha1; d=paypal.com; s=dkim;
c=relaxed/relaxed; q=dns/txt; i=@paypal.com; t=1344303087;
h=From:From:Subject:Date:To:MIME-Version:Content-Type;
bh=bzdID+5+r4f/a4cQslOlnyUEN5M=;
b=y/eUpnMcLYWmmEWMmRGNMAvG8MUtO4fKEO7rEgLufKVhTXHC3L3Vd0hbym9b8x6q
YUCvQx4/lcU+2YRDcMLkR8wTGagK9j23s3FZRzsOglmZurIwJkg4tLbcJzEy4/Hz
veD/f5lW6kFFDxUFxdSHvll/2TQdwqGQcGSxWficFxk=;
Date: Tue, 16 Oct 2012 11:12:31 +0000
Message-ID: <6663755...@paypal.com>
Subject: Notification of payment received
X-MaxCode-Template: email-wax-payment-notification
From: "serv...@paypal.com" <serv...@paypal.com>
To: <#ew...@nezumi.demon.co.uk>
Content-Type: multipart/mixed; boundary="----=a__vzkttogrbs_35_94_00"
X-MDF-HostID: 23
X-MDF-HostID: 2
Return-Path: stuffin...@paypal.com

X-MS-Exchange-Organization-AuthSource: HVUT01.thus.corp
X-MS-Exchange-Organization-AuthAs: Anonymous
MIME-Version: 1.0

------=a__vzkttogrbs_35_94_00
Content-Type: multipart/alternative; boundary="----=_vzkttogrbs_35_94_00"

------=_vzkttogrbs_35_94_00
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

BODY, TD {font-family: verdana,arial,helvetica,sans-serif;font-size: 12px=
---ends---

It made some effort to look like a PayPal emails too.

--
Regards,
Martin Brown

[Martin Brown]

On 16/10/2012 12:24, Martin Brown wrote:
> On 16/10/2012 12:01, Martin Brown wrote:
>> On 16/10/2012 10:49, Neil Jackson wrote:
>>
>>> Sadly, none of those 'fresh meat' spams contained DomainKeys signatures,
>>> so I'm not any closer to working out whether that's been exploited.

Here is another one that might have clues in as to how they are doing
it. The trailing header is pinched from Du Pont email traffic and not BA
as it claims but I reckon it was injected at Korea. Perhaps BA's system
resisted probing and it has reused old stolen data?

From - Wed Oct 17 10:13:17 2012
X-Account-Key: account3
X-UIDL: 1455

X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
X-Mozilla-Keys:

Received: from smtp.demon.co.uk (91.221.168.48) by HVUT02.thus.corp
(192.168.70.42) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed,
17 Oct
2012 10:02:44 +0100
Received: from mdfmta007.tbr.inty.net (unknown [127.0.0.1]) by
mdfmta007.tbr.inty.net (Postfix) with ESMTP id D0EB244C0BA for
<admini...@nezumi.demon.co.uk>; Wed, 17 Oct 2012 10:03:53 +0100 (BST)

Received: from mdfmta006.tbr.inty.net (unknown [127.0.0.1]) by

mdfmta006.tbr.inty.net (Postfix) with ESMTP id A919A3B418D for
<admini...@nezumi.demon.co.uk>; Wed, 17 Oct 2012 10:03:47 +0100 (BST)

Received: from mdfmta006.tbr.inty.net (unknown [127.0.0.1]) by

mdfmta006.tbr.inty.net (Postfix) with ESMTP id 2A9C83B40FE for
<as...@nezumi.demon.co.uk>; Wed, 17 Oct 2012 10:03:39 +0100 (BST)
Received: from [210.92.26.116] (unknown [210.92.26.116]) by

mdfmta006.tbr.inty.net (Postfix) with ESMTP for

<as...@nezumi.demon.co.uk>;
Wed, 17 Oct 2012 10:03:36 +0100 (BST)
Received: from [52.128.34.24] (helo=pzayvd.vouzfud.va) by with esmtpa (Exim
4.69) (envelope-from ) id 1MMLB0-7177ok-QU for
as...@nezumi.demon.co.uk; Wed,
17 Oct 2012 18:03:30 +0900
From: British Airways e-ticket <BA.e-...@email.ba.com>
To: <as...@nezumi.demon.co.uk>
Subject: BA e-ticket receipt
Date: Wed, 17 Oct 2012 18:03:30 +0900
X-Mailer: doicd_28
Message-ID: <7168202907.9...@nsoratsbsmgp.yfkzxtwdxzluncs.va>
Content-Type: multipart/mixed; boundary="----=a__ygxfhcb_03_01_97"
X-MDF-HostID: 23
X-MDF-HostID: 6
Return-Path: incontrove...@email.ba.com

X-MS-Exchange-Organization-AuthSource: HVUT02.thus.corp
X-MS-Exchange-Organization-AuthAs: Anonymous
MIME-Version: 1.0

------=a__ygxfhcb_03_01_97
Content-Type: multipart/alternative; boundary="----=_ygxfhcb_03_01_97"

------=_ygxfhcb_03_01_97
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

e-ticket receipt THIS IS AN AUTOMA=


I find it a little odd that the Vatican is talking to Du Pont but there
you go. Anyway it is a new one. eWoks booking BA flights in profusion.

--
Regards,
Martin Brown

[Neil Jackson]

On 17/10/2012 10:32, Martin Brown wrote:
> On 16/10/2012 12:24, Martin Brown wrote:
>> On 16/10/2012 12:01, Martin Brown wrote:
>>> On 16/10/2012 10:49, Neil Jackson wrote:
>>>
>>>> Sadly, none of those 'fresh meat' spams contained DomainKeys
>>>> signatures,
>>>> so I'm not any closer to working out whether that's been exploited.
>
> Here is another one that might have clues in as to how they are doing
> it.

Sadly, not. This one doesn't use DKIM/DomainKeys at all. It's just an
oldskool 'header injection lie' spam, using the injected header as an
attempt to mislead those who aren't pedantic when header-tracing and who
just jump to the last line.

> The trailing header is pinched from Du Pont email traffic

I believe it is intended to look that way, but isn't actually pinched;
it's made-up. Badly!

> and not BA
> as it claims but I reckon it was injected at Korea.

Correct.

>Perhaps BA's system
> resisted probing and it has reused old stolen data?

Doubtful. BA's systems are not involved in any way or stage of
mail-conversation with this one. They only appear as a faked 'From:'
address placed in the message header block by the spammer, and don't
appear to have been involved either from a transferring IP adddress/MTA
point of view, or as a 'MAIL FROM:' SMTP envelope spoof. In essence, the
reference to BA is purely random, and used simply as more obfuscation.

>
> From - Wed Oct 17 10:13:17 2012
> X-Account-Key: account3
> X-UIDL: 1455
> X-Mozilla-Status: 0001
> X-Mozilla-Status2: 00000000
> X-Mozilla-Keys:
> Received: from smtp.demon.co.uk (91.221.168.48) by HVUT02.thus.corp
> (192.168.70.42) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed,
> 17 Oct
> 2012 10:02:44 +0100
> Received: from mdfmta007.tbr.inty.net (unknown [127.0.0.1]) by
> mdfmta007.tbr.inty.net (Postfix) with ESMTP id D0EB244C0BA for
> <admini...@nezumi.demon.co.uk>; Wed, 17 Oct 2012 10:03:53 +0100 (BST)
> Received: from mdfmta006.tbr.inty.net (unknown [127.0.0.1]) by
> mdfmta006.tbr.inty.net (Postfix) with ESMTP id A919A3B418D for
> <admini...@nezumi.demon.co.uk>; Wed, 17 Oct 2012 10:03:47 +0100 (BST)
> Received: from mdfmta006.tbr.inty.net (unknown [127.0.0.1]) by
> mdfmta006.tbr.inty.net (Postfix) with ESMTP id 2A9C83B40FE for
> <as...@nezumi.demon.co.uk>; Wed, 17 Oct 2012 10:03:39 +0100 (BST)

Next (below) is the real source - as you rightly noted, a Korean Telecom
IP address. It's actually from the IP-Block registered as:

IPv4 address: 210.92.26.0 - 210.92.26.127 (/25)
Network Name: KORNET-10987124440
Organisation Name: jusighwyeusa keitisudogwongogaegsenteo
Organisation ID: ORG82658
Address: Sunhwa-dong, Jung-gu, Seoul
Zip Code: 100-130
Registration Date: 20070729
Publishes: N

Sadly, my Korean is not so good (read: entirely absent), so I'm not sure
what: "jusighwyeusa keitisudogwongogaegsenteo" means. It could be an ISP
(and most likely, is). Presumably it's one of their downstream clients'
machines that's been botnetted.

Robtex suggests that DNS info is sketchy (though I managed to find out
the above using the Korean Whois box at: http://whois.kisa.or.kr/eng/ )
- but Robtex reports the IP is in no fewer than NINE blacklists. Once
again, Demon really should have picked this one up at the door and
sinbinned it straight away (or even outright refused to accept). Asleep
on their feet, evidently.

It's moderately interesting that there is no evidence of any Demon
record of SPF-lookup. From that, I think we can infer that the domain of
the "MAIL FROM:" (SMTP envelope) did not return any SPF records in the
DNS at all when looked up, or, if it DID return SPF records, they
matched with the sending IP address (very doubtful, imho, given that the
connecting IP address was in Korea).

That all tends to rule out ba.com as having been cited as the "MAIL
FROM:" address that was supplied at MTA-handoff (SMTP) time... because
ba.com definitely DOES have TXT records in the DNS identifying their
mail IP addresses for SPF. Also, ba.com use hardfail (-all) in their SPF
records, so (assuming they're not inadvertantly vouching for Korean
domains, which I don't believe they are, LOL!) if the spammer had used
'[anything]@ba.com' as a "MAIL FROM:" SMTP envelope address, this would
have been rejected immediately by Demon (in accordance with their
'reject SPF hardfail' rules in force at the moment).

This assumes you've not been removed from Demon's SPF arrangements, of
course!

The upshot is, the 'MAIL FROM:' address has not been recorded anywhere
in the chain, so presumably it either was a spoofed address where the
spoofed domain has no SPF record (my guess), or an address that checks
out, SPF-wise, to the Korean IP address that was used (doubtful).

> Received: from [210.92.26.116] (unknown [210.92.26.116]) by
> mdfmta006.tbr.inty.net (Postfix) with ESMTP for
> <as...@nezumi.demon.co.uk>;
> Wed, 17 Oct 2012 10:03:36 +0100 (BST)

Here (below) is the 'header injection lie':

> Received: from [52.128.34.24] (helo=pzayvd.vouzfud.va) by with
> esmtpa (Exim
> 4.69) (envelope-from ) id 1MMLB0-7177ok-QU for
> as...@nezumi.demon.co.uk; Wed,
> 17 Oct 2012 18:03:30 +0900

The line format is incomplete for the type of MTA given (Exim), and is
missing the 'by' (receiving MTA) address that should be there before the
'with'.

The 'helo' reponse (ie the name which this line is trying to say it
identified itself with, when it talked to this receiving-MTA) is faked:
there is no DNS data for pzayvd.vouzfud.va - it's simply a made-up
hostname. It certainly doesn't correlate with 52.128.34.24, which as you
rightly say, is a DuPont IP address.

The remaining headers below are basically lies or inconsequential to
SMTP level deliveries/transferring. The 'To' here is relevant, of
course, but only for downstream use - the 'RCPT-TO' at the SMTP stage is
what really determines the mailbox this will end up in. The 'To' here is
just for your email client's benefit. The From, Message-ID and
Return-Path are all lies - utter ones. The other stuff are just
X-markers and have no purpose other than comments, basically.

> From: British Airways e-ticket <BA.e-...@email.ba.com>
> To: <as...@nezumi.demon.co.uk>
> Subject: BA e-ticket receipt
> Date: Wed, 17 Oct 2012 18:03:30 +0900
> X-Mailer: doicd_28
> Message-ID: <7168202907.9...@nsoratsbsmgp.yfkzxtwdxzluncs.va>
> Content-Type: multipart/mixed; boundary="----=a__ygxfhcb_03_01_97"
> X-MDF-HostID: 23
> X-MDF-HostID: 6
> Return-Path: incontrove...@email.ba.com
> X-MS-Exchange-Organization-AuthSource: HVUT02.thus.corp
> X-MS-Exchange-Organization-AuthAs: Anonymous
> MIME-Version: 1.0

> I find it a little odd that the Vatican is talking to Du Pont but there
> you go. Anyway it is a new one. eWoks booking BA flights in profusion.

IMHO, they didn't. The DuPont IP address has just been 'thrown together'
with a made up Vatican City hostname that doesn't actually exist, in
order to throw one off the scent. Intention being to cause the
spamfighter to direct abuse emails to the Vatican, Dupont, and BA. Good
oldskool obfuscation 101.

Gosh, I've not spent this long deconstructing spam for many years! Fun.

I'm still working on the DK/DKIM spooferage concept. I *think* I have an
idea how its done, but it seems to involve either the DKIM signing-party
to have been given the message and signed it somehow (which would imply
that the full message is vectored through Paypal.com or Bookers.com, as
appropriate, back to the spammer, in order to generate a message
body-hash and signatures that are 'valid' for the message content), and
then this 'signed' message is re-sent from the spammer to you. From what
I've read of DKIM today and before, it's basically just a wax-seal on
some of the message headers, and the message-body; if these are changed,
the signed body-hash will not match, and the party doing the lookup will
realise the message has been tampered with.

However, I can't find any tools that I can use to actually decrypt
hashes using their associated public keys, so I can't tell whether any
of the messages we've had, will actual 'unlock' when we use the domain
keys provided, or whether they 'add up' in terms of matching the actual
message-bodies and hashes in the fake messages.

I feel kind of confident that IF either of those two factors had
resulted in a 'no', and if Demon had looked it up and discovered that,
then they would've reported this in the message headers somewhere. The
fact that they didn't, leads me to think they are either simply ignoring
DomainKeys info, or it DID validate... somehow. And that latter outcome
is what is currently foxing me at the moment, because that's NOT
supposed to happen with DK!

TTFN
--
Neil

[Neil Jackson]

On 16/10/2012 11:51, Tony wrote:

> A browse of the Cloudmark website suggests that it depends on whether
> Demon/intY have included "Cloudmark Sender Intelligence" or not. See p10
> of the "Fixed Network Security Solutions Guide" at
> <http://www.cloudmark.com/releases/docs/solutionguides/Fixed%20Network%20
> Security%20Solutions%20Guide_July%202012.pdf>. It's still marked
> "Proprietary & Confidential", so burn after reading :)

Thanks for this info, Tony (and of course, my PC is smouldering nicely
atm, mission-impossible style ;) ).

Certainly it would seem that the 'CSI' feature would be where the RBL
action happens; or not. Interesting graph on Fig 8, showing that they
believe their RBL list to be a super-set of the information provided by
Spamhaus, et al. This is perfectly plausible (because they actually
'see' a lot of the spam firsthand, and their downstream cloud of users
who literally 'mark' the spam, provide much more info than the
individual RBLs are likely to obtain on their own).

However, the implication must be, then - if we are getting emails from
IP addresses that are hotter than the sun, in terms of existing on many
RBLs at once - that Demon do NEITHER 'normal RBL-checking', nor utilise
Cloudmark's CSI, surely?

Put another way, even if Demon weren't using CSI, and were instead just
reliant on Zen.Spamhaus or any one of a number of reputable RBLs, then
these emails would've stood out like a treen in a disabled spaceship
(which, as ne fule kno, is a reason for 504ing them into the
back-o'-beyond).

So why didn't they?

The only logical conclusion is that Demon's not using RBLs, per se,
surely? Or if they are, they're not doing much with the results of
positive hits.

TTFN
--
Neil

[Martin Brown]

On 16/10/2012 11:51, Tony wrote:

Thanks for that. Very interesting insight into behind the scenes in a
little bit more detail than is usually available.


--
Regards,
Martin Brown

[Martin Brown]

Hi Neil,

Thanks for all the detailed analysis. I have another interesting one
that is definitely from a purchased spammers list as the only ones that
refer to me with this handle are psychic charlatan spammers.

I don't know if this is a real forgery or a bunch of UK spammers.
Client IP isn't votingbritain.co.uk but their domain has allegedly given
this dross an SPF pass. I am out of my depth here! Anybody???

Looks like the bad guys may have beaten both DKIM and SPF.
I am confused. It has been a long day. Not much spam tho.

From - Mon Oct 22 22:21:50 2012
X-Account-Key: account3
X-UIDL: 1547

X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
X-Mozilla-Keys:

Received: from smtp.demon.co.uk (91.221.168.44) by HVUT02.thus.corp
(192.168.70.42) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon,
22 Oct
2012 22:11:09 +0100
Received: from mdfmta003.tbr.inty.net (unknown [127.0.0.1]) by
mdfmta003.tbr.inty.net (Postfix) with ESMTP id 10A7492C0FD for
<##########@nezumi.demon.co.uk>; Mon, 22 Oct 2012 22:12:39 +0100 (BST)
Received: from mdfmta003.tbr.inty.net (unknown [127.0.0.1]) by
mdfmta003.tbr.inty.net (Postfix) with ESMTP id DF44E92C0FE for
<##########@nezumi.demon.co.uk>; Mon, 22 Oct 2012 22:12:38 +0100 (BST)
Received: from mdfmta003.tbr.inty.net (unknown [127.0.0.1]) by
mdfmta003.tbr.inty.net (Postfix) with ESMTP id B8F4E92C0FD for
<#####@nezumi.demon.co.uk>; Mon, 22 Oct 2012 22:12:38 +0100 (BST)
Received-SPF: pass (mdfmta003.tbr.inty.net: domain of
votingbritain.co.uk designates 216.120.250.72 as permitted sender)
client-ip=216.120.250.72; envelope-from=bou...@votingbritain.co.uk;
helo=s4.votingbritain.co.uk;
Received: from s4.votingbritain.co.uk (unknown [216.120.250.72]) by
mdfmta003.tbr.inty.net (Postfix) with ESMTP for
<#####@nezumi.demon.co.uk>;
Mon, 22 Oct 2012 22:12:38 +0100 (BST)
Received: by s4.votingbritain.co.uk (Postfix, from userid 509) id
C5D895274A;
Mon, 22 Oct 2012 22:17:14 +0100 (BST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
d=votingbritain.co.uk; s=default; t=1350940634;
bh=Q4bzcnAoDnoE/FPoLUtblRM9DsTYK/Vk4zRI4KNlbDg=;
h=To:Subject:Message-ID:Date:From:Reply-To:MIME-Version:
List-Unsubscribe:Content-Type:Content-Transfer-Encoding;
b=DpbTTCaloLBBRehvqAv8kUSpXqubLJw7kB/61dyCilQGqsUAO69RmccKIcGNhCcSl
mYPXxdKvX9p8lFswy6pUOhRqN5nZGq+qlnTGNPIRMmXcau/wpq3jFrEdIjqK40VM2x
/TMDB3Mp9SIi7QGa/kiSjPOCqQoexUHnzyodZX50=
X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 s4.votingbritain.co.uk
C5D895274A
DomainKey-Signature: a=rsa-sha1; s=default; d=votingbritain.co.uk;
c=simple; q=dns;
b=jYSy7qo4SeSDmumBRyiSluUSHBvms78ro5gkQZYUNvu90sHFKX7azP4DM74NSDxRi
Puqy8WXyeqzzSMrSUC+NA0icoQVEHxiBP86V0bmjgynJPUPcWJRLV0NCal2QUhNLo3K
6LDdauhSsWTvKX79KcdKsFFIX2+i7au2TIbO4JU=
Received: from votingbritain.co.uk (s4.votingbritain.co.uk [216.120.250.72])
by s4.votingbritain.co.uk (Postfix) with ESMTP id 90372526AD for
<#####@nezumi.demon.co.uk>; Mon, 22 Oct 2012 22:17:14 +0100 (BST)
X-GreenArrow-MtaID: votingbritain.co.uk
X-GreenArrow-ListID: z23
X-GreenArrow-SendID: z428
To: Mrs Deborah ###### <#####@nezumi.demon.co.uk>
Subject: Mrs Deborah ###### Enter today for a £300 Amazon Gift Card
Message-ID: <05ab2881a63eb9f0...@votingbritain.co.uk>
Date: Mon, 22 Oct 2012 22:12:37 +0100
From: Spoiled by choice <spoiled...@votingbritain.co.uk>
Reply-To: <re...@votingbritain.co.uk>
X-Mailer-LID: 23
List-Unsubscribe:
<http://www.votingbritain.co.uk/emailflow/unsubscribe.php?M=2096970&C=39639e041f0a0e4c58928553330b70a1&L=23&N=428>
X-Mailer-SID: 428
X-Mailer-Sent-By: 7
X-Mailer: Email Flow::Enterprise 0.5
X-Mailer-Info: BQV0oFk4nP5vpP5uLaclpF52rzugpzSNLKMaMJ56YQZloD
X-JobID: 434
X-Envid: 1350940357-2096970
X-CampaignID: marketingsource:434
Content-Type: multipart/alternative; charset="UTF-8";
boundary="b1_8abdd4136285d9e0786b97ac2bbfc1f9"
Content-Transfer-Encoding: 8bit
X-MDF-HostID: 10
X-MDF-HostID: 10
Return-Path: bou...@votingbritain.co.uk

X-MS-Exchange-Organization-AuthSource: HVUT02.thus.corp
X-MS-Exchange-Organization-AuthAs: Anonymous
MIME-Version: 1.0

--b1_8abdd4136285d9e0786b97ac2bbfc1f9
Content-Type: text/plain; format=flowed; charset="UTF-8"
Content-Transfer-Encoding: 8bit


Could be a dumb UK company that has bought a spammers list or a psychic
that has moved on from fortune telling to direct marketing spam.

Thanks for any enlightenment.

--
Regards,
###### Brown

[Simon Turner]

On Monday, in article <R5jhs.19$9m...@newsfe05.iad>

|||newspam|||@nezumi.demon.co.uk "Martin Brown" wrote:

> I don't know if this is a real forgery or a bunch of UK spammers.
> Client IP isn't votingbritain.co.uk but their domain has allegedly given
> this dross an SPF pass.

The connecting IP is [216.120.250.72], which is s4.votingbritain.co.uk,
and is listed in votingbritain.co.uk's SPF records as a permitted
sender:

votingbritain.co.uk IN TXT "v=spf1 ip4:216.120.250.145
ip4:216.120.250.42 ip4:216.120.250.43 ip4:216.120.250.72 << N.B.
ip4:216.120.250.73 ip4:208.92.234.74 a mx -all"

votingbritain.co.uk IN TXT "v=spf2.0/pra mx ip4:216.120.250.145
ip4:216.120.250.42 ip4:216.120.250.43 ip4:216.120.250.72 << N.B.
ip4:216.120.250.73 ip4:208.92.234.74 -all"

> Looks like the bad guys may have beaten both DKIM and SPF.

I don't think so; from a quick glance, this appears to have been
genuinely sent by votingbritain.co.uk -- I can't see any obvious header
forgery. The DKIM and SPF stuff appears normal and above board.

Excerpted header fields:

> Received-SPF: pass (mdfmta003.tbr.inty.net: domain of
> votingbritain.co.uk designates 216.120.250.72 as permitted sender)
> client-ip=216.120.250.72; envelope-from=bou...@votingbritain.co.uk;
> helo=s4.votingbritain.co.uk;

> Received: from s4.votingbritain.co.uk (unknown [216.120.250.72]) by
> mdfmta003.tbr.inty.net (Postfix) with ESMTP for
> <#####@nezumi.demon.co.uk>;
> Mon, 22 Oct 2012 22:12:38 +0100 (BST)

> Message-ID: <05ab2881a63eb9f0...@votingbritain.co.uk>

> From: Spoiled by choice <spoiled...@votingbritain.co.uk>
> Reply-To: <re...@votingbritain.co.uk>

> Return-Path: bou...@votingbritain.co.uk

All looks perfectly plausible to me. But maybe I've missed something;
Neil?

> Could be a dumb UK company that has bought a spammers list

That would be my guess.

--
Simon Turner DoD #0461
si...@twoplaces.co.uk
Trust me -- I know what I'm doing! -- Sledge Hammer

[Martin Brown]

On 23/10/2012 13:21, Simon Turner wrote:
> On Monday, in article <R5jhs.19$9m...@newsfe05.iad>
> |||newspam|||@nezumi.demon.co.uk "Martin Brown" wrote:
>
>> I don't know if this is a real forgery or a bunch of UK spammers.
>> Client IP isn't votingbritain.co.uk but their domain has allegedly given
>> this dross an SPF pass.
>
> The connecting IP is [216.120.250.72], which is s4.votingbritain.co.uk,

Sigh I got back something else entirely. I did it wrong :(

> and is listed in votingbritain.co.uk's SPF records as a permitted
> sender:
>
> votingbritain.co.uk IN TXT "v=spf1 ip4:216.120.250.145
> ip4:216.120.250.42 ip4:216.120.250.43 ip4:216.120.250.72 << N.B.
> ip4:216.120.250.73 ip4:208.92.234.74 a mx -all"
>
> votingbritain.co.uk IN TXT "v=spf2.0/pra mx ip4:216.120.250.145
> ip4:216.120.250.42 ip4:216.120.250.43 ip4:216.120.250.72 << N.B.
> ip4:216.120.250.73 ip4:208.92.234.74 -all"
>
>> Looks like the bad guys may have beaten both DKIM and SPF.
>
> I don't think so; from a quick glance, this appears to have been
> genuinely sent by votingbritain.co.uk -- I can't see any obvious header
> forgery. The DKIM and SPF stuff appears normal and above board.

Oops. When I checked it I got "votingbritain.co.uk" is available for $38
which made me think that it was bogus.

http://www.whois.net/whois/votingbritain.co.uk

But you are right. An attempt to buy the domain reveals it is taken.

>> From: Spoiled by choice <spoiled...@votingbritain.co.uk>
>> Reply-To: <re...@votingbritain.co.uk>
>
>> Return-Path: bou...@votingbritain.co.uk
>
> All looks perfectly plausible to me. But maybe I've missed something;
> Neil?
>
>> Could be a dumb UK company that has bought a spammers list
>
> That would be my guess.

I have left their various email addresses in so they can benefit from
the attention of any harvesters.

My excuse is that it was late at night...

--
Regards,
Martin Brown

[Neil Jackson]

On 22/10/2012 22:43, Martin Brown wrote:
> Hi Neil,
>
> Thanks for all the detailed analysis. I have another interesting one
> that is definitely from a purchased spammers list as the only ones that
> refer to me with this handle are psychic charlatan spammers.
>
> I don't know if this is a real forgery or a bunch of UK spammers.
> Client IP isn't votingbritain.co.uk but their domain has allegedly given
> this dross an SPF pass. I am out of my depth here! Anybody???

"bunch of UK spammers" would seem about the most appropriate choice,
from those two.

>
> Looks like the bad guys may have beaten both DKIM and SPF.
> I am confused. It has been a long day. Not much spam tho.

DomainKey and DKIM sigs look apparently genuine (I haven't gone to the
extent of trying to decode them, because it would be fairly pointless
without the entire message-body, and wouldn't tell us much new anyway).
I can't tell whether Demon has looked at these and taken any action or
decisions upon them. If they have, it's not recorded in any obvious way.

As for the SPF record, it checks out. The mail arrived at Inty from a
box called s4.votingbritain.co.uk and that's within the netblock vouched
for by votingbritain.co.uk's SPF record.

In a nutshell, then, this came in from a 'reputable' (in the sense of
SPF-reputing-for-itself) source.

Further upstream, although there is one instance where
s4.votingbritain.co.uk doesn't fully record its incoming source (which
it refers to as user 509), I believe this is just loopback evidence; the
box seems to be talking to itself (much as the Inty boxes do sometimes),
except it does so using it's external WAN IP address rather than
localhost, while it's generating its DK/DKIM signatures for inclusion.

Everything else in the message looks 'pukka' (as far as can be
established) and totally in line with what this company seems to provide
- have a look at their website for an idea of the 'service' (their
words, not mine) which they offer.

They seem to have registered their domain via 123-reg and they give a UK
address in Exmouth, Devon - but their net connection seems to be
emanating from the USA (possibly Philadelphia), but it's rather hard to
be totally sure.

Clearly, if the email address they're using a non-existent and can only
have been farmed rather than given willingly, then they're breaking the
Office of the Information Commissioner rules. You could file a report
there, or just yell down the toilet - whichever you felt was more
effective. You could try the unsubscribe link (though I am always wary
of these) to see whether Votingbritain is as clean as they say they are.
I have no indication that they've been spammer blacklist at any of the
usual sources, so maybe they have just obtained your email through
normally-legitimate sources that have in turn been compromised. It
*might* be worth talking to them directly and seeing whether they are
nice people or dirty spammers - at least then you'd have an opinion you
could share with the blacklists, etc.

But basically, this one is 'genuine', even though it is spam. There
don't appear to be any hi-jinks or attempts at obfuscation going on here.

[Martin Brown]

On 23/10/2012 13:46, Neil Jackson wrote:
> On 22/10/2012 22:43, Martin Brown wrote:

> Clearly, if the email address they're using a non-existent and can only
> have been farmed rather than given willingly, then they're breaking the
> Office of the Information Commissioner rules. You could file a report
> there, or just yell down the toilet - whichever you felt was more
> effective.

The latter seems more likely to work and it is quicker too.

Last time I did an ICO complaint for a particularly bad ambulance
chasing solicitors spam and guess what I got back from the dozy
bastards? Mailbox full error on the recipients address and indications
in the header that had it not failed for "disk quota exceeded" it would
have been rejected as *spam*. I would not pay them in lead washers.

> You could try the unsubscribe link (though I am always wary
> of these) to see whether Votingbritain is as clean as they say they are.
> I have no indication that they've been spammer blacklist at any of the
> usual sources, so maybe they have just obtained your email through
> normally-legitimate sources that have in turn been compromised. It
> *might* be worth talking to them directly and seeing whether they are
> nice people or dirty spammers - at least then you'd have an opinion you
> could share with the blacklists, etc.
>
> But basically, this one is 'genuine', even though it is spam. There
> don't appear to be any hi-jinks or attempts at obfuscation going on here.

In this case I blame user error (ie. me!). Sorry for the waste of time.

--
Regards,
Martin Brown

[Andy]

In message <20121023.12...@twoplaces.co.uk>, Simon Turner
<si...@twoplaces.co.uk> wrote
[]

>> Could be a dumb UK company that has bought a spammers list
>
>That would be my guess.
>

Glancing at their web site is unlikely to alter it :)

"At VotingBritain, we're passionate about using email to inform
you of the latest promotions which might benefit you. It's a big
world out there, and who knows how many offers there might be to
save your hard-earned cash."


--
Andy Taylor [Editor, Austrian Philatelic Society].
Visit <URL:http://www.austrianphilately.com>

[Neil Jackson]

On 23/10/2012 13:56, Martin Brown wrote:
> On 23/10/2012 13:46, Neil Jackson wrote:
>> On 22/10/2012 22:43, Martin Brown wrote:
>
>> Clearly, if the email address they're using a non-existent and can only
>> have been farmed rather than given willingly, then they're breaking the
>> Office of the Information Commissioner rules. You could file a report
>> there, or just yell down the toilet - whichever you felt was more
>> effective.
>
> The latter seems more likely to work and it is quicker too.
>
> Last time I did an ICO complaint for a particularly bad ambulance
> chasing solicitors spam and guess what I got back from the dozy
> bastards? Mailbox full error on the recipients address and indications
> in the header that had it not failed for "disk quota exceeded" it would
> have been rejected as *spam*. I would not pay them in lead washers.

Par for the course. My experiences with them (and the old ICSTIS lot,
whatever they're called now) was marginally less fruitful than hitting
my own testicles with a breeze-block strapped to a circular saw. I
shan't do either again, I think. :)

[snip]

> In this case I blame user error (ie. me!). Sorry for the waste of time.

S'alright, never a total waste. It's nice to have the odd 'control' to
test occasionally - keeps one on one's toes.

TTFN
--
Neil

[Simon Turner]

On Tuesday, in article <rdwhs.1$MP...@newsfe05.iad>

|||newspam|||@nezumi.demon.co.uk "Martin Brown" wrote:

> Oops. When I checked it I got "votingbritain.co.uk" is available for $38
> which made me think that it was bogus.
>
> http://www.whois.net/whois/votingbritain.co.uk

It would appear that whois.net are only useful for the .com/.org./.net
etc. gTLDs. They know nothing whatsoever about .uk domains, claiming
that they are all available:

http://www.whois.net/whois/demon.co.uk

A quick search provided http://www.whois-search.com/, who seem to be a
better whois proxy (they get results for ccTLDs as well as gTLDs), but
there are many many others. (The geektools one used to be good, but now
it requires a CAPTCHA which is a pain.)

> >> Could be a dumb UK company that has bought a spammers list
> >
> > That would be my guess.
>
> I have left their various email addresses in so they can benefit from
> the attention of any harvesters.

8-)

[David Rance]

On Tue, 23 Oct 2012 Simon Turner wrote:

>On Tuesday, in article <rdwhs.1$MP...@newsfe05.iad>
> |||newspam|||@nezumi.demon.co.uk "Martin Brown" wrote:
>
>> Oops. When I checked it I got "votingbritain.co.uk" is available for $38
>> which made me think that it was bogus.
>>
>> http://www.whois.net/whois/votingbritain.co.uk
>
>It would appear that whois.net are only useful for the .com/.org./.net
>etc. gTLDs. They know nothing whatsoever about .uk domains, claiming
>that they are all available:
>
> http://www.whois.net/whois/demon.co.uk

They told me that my registered domain, which is ****.org.uk, is not
available - so they seem to know about that!

David

--
David Rance writing from Caversham, Reading, UK

[Simon Turner]

On Tuesday, in article <fwOnCdNl...@david.rance.org.uk>

Hmmm; my earlier checks were clearly too limited. Actually, they don't
know about your domain: they claim that all *.org.uk are unavailable
(even those that are unregistered). 8-/

The same is true (unavailable) for all other *.uk domains; obviously
*.co.uk is a special case (always available, until you actually try to
buy it, at which point they do a proper check which -- shock, horror --
actually seems to give the correct result).

If you look at their domain name registration page, they only sell the
main US gTLDs (.com/net/org/info/us/biz) plus .co.uk; they actually seem
to do the WHOIS checks correctly on that page (except that they can't
display the .co.uk WHOIS results, which may explain a thing or two).

All in all, they haven't got much of a clue outside the USA. Quelle
surprise.

[Tony]

Neil Jackson <ja...@techno.demon.co.uk.invalid> wrote on Fri, 12 Oct
2012 at 18:36:29:

>Off to look for DK exploits! :-)

You might enjoy
<http://www.wired.co.uk/news/archive/2012-10/25/google-email>.
--
Tony

[Neil Jackson]

Wow. Chuffin' splendid, Tony. Thanks so much for that! I have been so
busy these last couple of weeks, I've not been able to devote much time
to this problem, but it would seem moot now.

Just to summarise... some companies (including Paypal) appear to have
been using DKIM keys that were less than the 1024-bit size called for by
the standard. With the result that they can be cracked relatively
simply. Once a key is cracked, it's relatively simple for Johnny Haxx0r
to start signing messages with DKIM signatures derived from that cracked
private key, and lo and behold, they look 'real' (at least in terms of
the DKIM key.

It seems likely this is what was happening with the emails Martin was
showing us recently. Looking back, I can't even get
smtpapi._domainkey.sg.booking.com to resolve anymore, let alone find any
key data there now, so my guess is they have either given up completely
with DKIM, or are using a new s-part on their DK url (i.e. no longer
'smtpapi'). I'd need to see a real booking.com email to be able to work
out where their new keystore is, and whether it's greater-than 1024-bits
in length.

I does make me rather scared (in between the chuckles) to read that
companies of the ilk of Google, HSBC and others who really ought to know
better, have been using DKIM with substandard keys. It's many of these
same w*nkers who put such sway in the likes of DKIM, SPF and other such
half-baked anti-spam/message-verification systems that they clearly know
f*ck all about.

I think I shall burn some effigies this bonfire night.

Thanks again for the new story, Tony - very, very interesting!
--
Neil

[Martin Brown]

On 30/10/2012 18:16, Neil Jackson wrote:
> On 26/10/2012 21:02, Tony wrote:
>> Neil Jackson <ja...@techno.demon.co.uk.invalid> wrote on Fri, 12 Oct
>> 2012 at 18:36:29:
>>> Off to look for DK exploits! :-)
>>
>> You might enjoy
>> <http://www.wired.co.uk/news/archive/2012-10/25/google-email>.
>
> Wow. Chuffin' splendid, Tony. Thanks so much for that! I have been so
> busy these last couple of weeks, I've not been able to devote much time
> to this problem, but it would seem moot now.
>
> Just to summarise... some companies (including Paypal) appear to have
> been using DKIM keys that were less than the 1024-bit size called for by
> the standard. With the result that they can be cracked relatively
> simply. Once a key is cracked, it's relatively simple for Johnny Haxx0r
> to start signing messages with DKIM signatures derived from that cracked
> private key, and lo and behold, they look 'real' (at least in terms of
> the DKIM key.

This is pretty alarming that places like Google who are usually on the
ball have used inadequate cryptographic security. Amazing that it is
worthwhile cracking the 512bit DKIM keys for spammed bulk UCE tho.

>
> It seems likely this is what was happening with the emails Martin was
> showing us recently. Looking back, I can't even get
> smtpapi._domainkey.sg.booking.com to resolve anymore, let alone find any
> key data there now, so my guess is they have either given up completely
> with DKIM, or are using a new s-part on their DK url (i.e. no longer
> 'smtpapi'). I'd need to see a real booking.com email to be able to work
> out where their new keystore is, and whether it's greater-than 1024-bits
> in length.

I haven't got a recent one but here is a genuine one from August:

Received-SPF: pass (mdfmta006.tbr.inty.net: domain of mailer.booking.com
designates 62.190.24.30 as permitted sender) client-ip=62.190.24.30;
envelope-from=nor...@mailer.booking.com; helo=memta-03.booking.com;
Received: from memta-03.booking.com (unknown [62.190.24.30]) (using
TLSv1 with
cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate
requested)

by mdfmta006.tbr.inty.net (Postfix) with ESMTP for

<m######@nezumi.demon.co.uk>; Tue, 21 Aug 2012 13:12:54 +0100 (BST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
d=booking.com; s=me;
h=Message-Id:From:To:Reply-To:Sender:Subject:Date:Content-Type:Content-Transfer-Encoding:MIME-Version;
bh=ybxG0T78H5FuUTfmSA0JZiBVx/0SfgTCeDmP+hfGFtg=;
b=di1adw3Mi0oODlprZD5GRjLbck5bsr4vXGrvcoMujUsTe3/K3O0kzEY7oqRHSNNLuNFbdkEFXt3tUf3NZCR8r+6ynYYLTmn9V0xJowks4eWTd7VJ/kTe/0f4rwno0LqT1kLVLE3zHJBG2nxMHBb8hW7rX9m0UaLQTQHItRTuYVM=;
Received: from pc02me-01.prod.lhr1.booking.com ([10.141.11.22]:52071
helo=localhost.localdomain) by memta-03.prod.lhr1.booking.com with esmtp
(Exim 4.76) (envelope-from <nor...@mailer.booking.com>) id
1T3nKH-0003xr-UB
for m######@nezumi.demon.co.uk; Tue, 21 Aug 2012 14:12:53 +0200


Try s=me and cross fingers. Still looks to be 256 bit RSA though.

One other indicator is that fakes are Booking.com in the from field
whereas genuine ones at present are all lower case. I just noticed on
fake has got into my real inbox as a result of poking around.

>
> I does make me rather scared (in between the chuckles) to read that
> companies of the ilk of Google, HSBC and others who really ought to know
> better, have been using DKIM with substandard keys. It's many of these
> same w*nkers who put such sway in the likes of DKIM, SPF and other such
> half-baked anti-spam/message-verification systems that they clearly know
> f*ck all about.
>
> I think I shall burn some effigies this bonfire night.
>
> Thanks again for the new story, Tony - very, very interesting!

And thoroughly alarming! It pays to be paranoid...

--
Regards,
Martin Brown

[Neil Jackson]

On 31/10/2012 16:58, Martin Brown wrote:
>
> I haven't got a recent one but here is a genuine one from August:

[snip]

> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
> d=booking.com; s=me;
> h=Message-Id:From:To:Reply-To:Sender:Subject:Date:Content-Type:Content-Transfer-Encoding:MIME-Version;
> bh=ybxG0T78H5FuUTfmSA0JZiBVx/0SfgTCeDmP+hfGFtg=;
> b=di1adw3Mi0oODlprZD5GRjLbck5bsr4vXGrvcoMujUsTe3/K3O0kzEY7oqRHSNNLuNFbdkEFXt3tUf3NZCR8r+6ynYYLTmn9V0xJowks4eWTd7VJ/kTe/0f4rwno0LqT1kLVLE3zHJBG2nxMHBb8hW7rX9m0UaLQTQHItRTuYVM=;

[snip]

> Try s=me and cross fingers. Still looks to be 256 bit RSA though.

Nope - I'm told by a crypto expert whom I've been badgering for help
today, that the key in the DNS is stored in Base64 format, and (when
unravelled) actually turns out to be 1024-bits long.

Firstly, the data in the DKIM-Signature is perhaps misleading. The
'a=rsa-sha256' parameter merely signals that the message-body and
(separately) its headers and a blanked DKIM sig-block have been hashed
using a secure hashing algorithm in SHA-256 format. That is, the 256
here refers to the SHA, not the RSA. The second of these two hashes is
then signed with the private RSA key and this is what we see as the
value in 'b=' in the DKIM sig-block.

It's also fair to say that the data in the message signature is not the
key, it's the result of *using* the key, so in that regard, it's
unrelated (directly), and is not be viable to use to work out the
key-length used.

Digging the DNS at me._domainkey.booking.com did indeed reveal a TXT
record with a DKIM RSA key, which has 216 characters in it - but as I
said, this is Base64 encoded, and when decoded, reveals an RSA key of
1024-bit length.

In tests I did (and/or got done) today, Twitter's DKIM signature is
similarly 1024-bits long; Google's is (since 30th Oct, at least - LOL)
2048-bits.

On the face of it, then, I'd be surprised if the Booking.com DKIM
private key has been 'factored' (i.e. cracked). In other words, we're
probably just looking at a 'duff' key, robbed from another message
(probably the donor message that gave the spammer the other received
headers that were used for fakery and injection into the trace). I would
guess (but have not yet confirmed) that they would not, if checked,
validate the message-body nor the headers+body combo.

Unfortunately, it'll be hard (impossible, actually) to check the
veracity of this data without an unadulterated, complete original
message, as-received, but tbh, it'll be pretty hard even with one. I've
not yet found any online resource that lets me validate a DKIM-signed
message in one step: I'd have to physically hash, combine, re-hash and
compute the results, and then compare that against the signature ('b'
tag) decrypted with the public-key, all manually - and that's not a
simple task without the right tools (most of which barely exist on
Windows in a form that can be played with easily).

So - for the time being, let's assume, given that the key-strength is
probably too hard for cheap cracking, that it's just a dummy signature =
which in turn may be evidence that Demon is simply ignoring DKIM
signatures, after all.

If so, it's mighty funny how they put so much stead in SPF, and so
little in DKIM. IMHO, both are flawed, but it seems churlish to respect
one so vehemently, and yet completely ignore the other. And to do all
that whilst ignoring the good-old, well-proven RBL IP-address lookups
really does seem naíve - given that that step alone would probably have
nuked 99% of these booking.com malware-zip spams right off the bat.

TTFN
--
Neil

[Tony]

Neil Jackson <ja...@techno.demon.co.uk.invalid> wrote on Tue, 6 Nov 2012
at 16:13:40:

>So - for the time being, let's assume, given that the key-strength is
>probably too hard for cheap cracking, that it's just a dummy signature
>= which in turn may be evidence that Demon is simply ignoring DKIM
>signatures, after all.

That's all fascinating. Thanks for investigating!
--
Tony

[Brian]

On 06-11-2012, Neil Jackson <ja...@techno.demon.co.uk.invalid> wrote:

> So - for the time being, let's assume, given that the key-strength is
> probably too hard for cheap cracking, that it's just a dummy signature =
> which in turn may be evidence that Demon is simply ignoring DKIM
> signatures, after all.

Ok, we will assume that.

> If so, it's mighty funny how they put so much stead in SPF, and so
> little in DKIM. IMHO, both are flawed, but it seems churlish to respect
> one so vehemently, and yet completely ignore the other. And to do all
> that whilst ignoring the good-old, well-proven RBL IP-address lookups
> really does seem naíve - given that that step alone would probably have
> nuked 99% of these booking.com malware-zip spams right off the bat.

Who knows what is going on?

As for nuking mail addressed to this domain - I don't want it to happen.
0% nuking is my desire. I want that 99%, Why do you want to deprive me
of it? Is it for my good or your good? I couldn't care less whether
Demon use SPF, DKIM or RBL. Just give me the choice to opt out of email
censoring. I can deal with my own mail. If anyone wants Demon's concept
of what is acceptable mail they can have it as far as I am concerned.
Just don't give it to me.

[Martin Brown]

On 06/11/2012 16:13, Neil Jackson wrote:
> On 31/10/2012 16:58, Martin Brown wrote:
>>
>> I haven't got a recent one but here is a genuine one from August:
>
> [snip]
>> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
>> d=booking.com; s=me;
>> h=Message-Id:From:To:Reply-To:Sender:Subject:Date:Content-Type:Content-Transfer-Encoding:MIME-Version;
>>
>> bh=ybxG0T78H5FuUTfmSA0JZiBVx/0SfgTCeDmP+hfGFtg=;
>> b=di1adw3Mi0oODlprZD5GRjLbck5bsr4vXGrvcoMujUsTe3/K3O0kzEY7oqRHSNNLuNFbdkEFXt3tUf3NZCR8r+6ynYYLTmn9V0xJowks4eWTd7VJ/kTe/0f4rwno0LqT1kLVLE3zHJBG2nxMHBb8hW7rX9m0UaLQTQHItRTuYVM=;
>>
> [snip]
>
>> Try s=me and cross fingers. Still looks to be 256 bit RSA though.
>
> Nope - I'm told by a crypto expert whom I've been badgering for help
> today, that the key in the DNS is stored in Base64 format, and (when
> unravelled) actually turns out to be 1024-bits long.

Hi Neil,

Thanks for this update. Hope your cold is better now.

>
> Firstly, the data in the DKIM-Signature is perhaps misleading. The
> 'a=rsa-sha256' parameter merely signals that the message-body and
> (separately) its headers and a blanked DKIM sig-block have been hashed
> using a secure hashing algorithm in SHA-256 format. That is, the 256
> here refers to the SHA, not the RSA. The second of these two hashes is
> then signed with the private RSA key and this is what we see as the
> value in 'b=' in the DKIM sig-block.
>
> It's also fair to say that the data in the message signature is not the
> key, it's the result of *using* the key, so in that regard, it's
> unrelated (directly), and is not be viable to use to work out the
> key-length used.
>
> Digging the DNS at me._domainkey.booking.com did indeed reveal a TXT
> record with a DKIM RSA key, which has 216 characters in it - but as I
> said, this is Base64 encoded, and when decoded, reveals an RSA key of
> 1024-bit length.

I am well out of my depth on this stuff and more or less reduced to
guessing at the interpretation of the DKIM headers.

>
> In tests I did (and/or got done) today, Twitter's DKIM signature is
> similarly 1024-bits long; Google's is (since 30th Oct, at least - LOL)
> 2048-bits.

So that bit *is* true then.

>
> On the face of it, then, I'd be surprised if the Booking.com DKIM
> private key has been 'factored' (i.e. cracked). In other words, we're
> probably just looking at a 'duff' key, robbed from another message
> (probably the donor message that gave the spammer the other received
> headers that were used for fakery and injection into the trace). I would
> guess (but have not yet confirmed) that they would not, if checked,
> validate the message-body nor the headers+body combo.

It may been cracked earlier when it was shorter but is robust now. The
booking.com etc spams do seem to have abated.

>
> Unfortunately, it'll be hard (impossible, actually) to check the
> veracity of this data without an unadulterated, complete original
> message, as-received, but tbh, it'll be pretty hard even with one. I've
> not yet found any online resource that lets me validate a DKIM-signed
> message in one step: I'd have to physically hash, combine, re-hash and
> compute the results, and then compare that against the signature ('b'
> tag) decrypted with the public-key, all manually - and that's not a
> simple task without the right tools (most of which barely exist on
> Windows in a form that can be played with easily).

And probably not worth the effort.

>
> So - for the time being, let's assume, given that the key-strength is
> probably too hard for cheap cracking, that it's just a dummy signature =
> which in turn may be evidence that Demon is simply ignoring DKIM
> signatures, after all.

Seems likely now with 1024 bit keys in use but was it a month ago?

>
> If so, it's mighty funny how they put so much stead in SPF, and so
> little in DKIM. IMHO, both are flawed, but it seems churlish to respect
> one so vehemently, and yet completely ignore the other. And to do all
> that whilst ignoring the good-old, well-proven RBL IP-address lookups
> really does seem naíve - given that that step alone would probably have
> nuked 99% of these booking.com malware-zip spams right off the bat.
>
> TTFN

Thanks again for your help and your tame crypto analysist's too.

--
Regards,
Martin Brown

[Neil Jackson]

On 06/11/2012 20:05, Martin Brown wrote:
> On 06/11/2012 16:13, Neil Jackson wrote:
>> On 31/10/2012 16:58, Martin Brown wrote:
>>>
>>> I haven't got a recent one but here is a genuine one from August:
>>
>> [snip]
>>> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
>>> d=booking.com; s=me;
>>> h=Message-Id:From:To:Reply-To:Sender:Subject:Date:Content-Type:Content-Transfer-Encoding:MIME-Version;
>>>
>>>
>>> bh=ybxG0T78H5FuUTfmSA0JZiBVx/0SfgTCeDmP+hfGFtg=;
>>> b=di1adw3Mi0oODlprZD5GRjLbck5bsr4vXGrvcoMujUsTe3/K3O0kzEY7oqRHSNNLuNFbdkEFXt3tUf3NZCR8r+6ynYYLTmn9V0xJowks4eWTd7VJ/kTe/0f4rwno0LqT1kLVLE3zHJBG2nxMHBb8hW7rX9m0UaLQTQHItRTuYVM=;
>>>
>>>
>> [snip]
>>
>>> Try s=me and cross fingers. Still looks to be 256 bit RSA though.
>>
>> Nope - I'm told by a crypto expert whom I've been badgering for help
>> today, that the key in the DNS is stored in Base64 format, and (when
>> unravelled) actually turns out to be 1024-bits long.
>
> Hi Neil,
>
> Thanks for this update. Hope your cold is better now.

LOL - the cold - I'd forgotten about that. Since the gastroenteritis!
Getting over that now too, thank God. Been a strange couple of weeks!

[snip]

>>
>> Digging the DNS at me._domainkey.booking.com did indeed reveal a TXT
>> record with a DKIM RSA key, which has 216 characters in it - but as I
>> said, this is Base64 encoded, and when decoded, reveals an RSA key of
>> 1024-bit length.
>
> I am well out of my depth on this stuff and more or less reduced to
> guessing at the interpretation of the DKIM headers.

The DKIM RFC has a lot of detail in it about how things work - but I
won't pretend it's an easy read. It's taken me several passes to get a
'working grasp' of it, but I would still shy clear of saying I fully
understand it from a practical perspective. Again, the absence of decent
tools to toy with, makes life difficult. I like to experiment while
learning, and so far, it's been a bit dry! (understatement!)

>>
>> In tests I did (and/or got done) today, Twitter's DKIM signature is
>> similarly 1024-bits long; Google's is (since 30th Oct, at least - LOL)
>> 2048-bits.
>
> So that bit *is* true then.

Yup. The Google key I checked was referred-to in a newsletter email from
Google Earth dated 30th October, but to be totally factual, I don't know
exactly when it became a 2048-bit key. It *may* still have been 512-bit
on 30th Oct, for all I know; all I can really tell is that it is
2048-bit today.

I notice that Wikipedia also carries references to the same incident (or
at least, the fact that some companies were using low-grade DKIM RSA
keys) from October 2012, on the page about either DKIM or RSA keys. Alas
I can't remember exactly which one, but I happened upon it earlier today
- so presumably it's been verified by enough independent sources to be
at least relatively likely! :)

>>
>> On the face of it, then, I'd be surprised if the Booking.com DKIM
>> private key has been 'factored' (i.e. cracked). In other words, we're
>> probably just looking at a 'duff' key, robbed from another message
>> (probably the donor message that gave the spammer the other received
>> headers that were used for fakery and injection into the trace). I would
>> guess (but have not yet confirmed) that they would not, if checked,
>> validate the message-body nor the headers+body combo.
>
> It may been cracked earlier when it was shorter but is robust now. The
> booking.com etc spams do seem to have abated.

Quite possibly so. In point of fact, by way of comparison, Google
Earth's monthly newsletter has pointed to a DKIM key on
20120113_.domainkey.google.com since at least July 2012, probably
earlier, and is still referring to it now. Given what the tale says
about their weak keys up to October, if they've changed the key now,
they've not changed its DNS location. Presumably this means that old
messages would not now validate using that new key, but that probably
doesn't matter now because they have already been delivered long since.

It does seem a bit odd to swap a key 'in-situ'... I would thought that
posed problems downstream (possibly). But it does seem to be exactly
what Google have done (at least for the Google Earth newsletters), so
there's every possibility that Booking.com might have done exactly the
same thing, and what I'm looking at now is a 'new' key which wasn't in
place when the spam was circulating.

>>
>> Unfortunately, it'll be hard (impossible, actually) to check the
>> veracity of this data without an unadulterated, complete original
>> message, as-received, but tbh, it'll be pretty hard even with one. I've
>> not yet found any online resource that lets me validate a DKIM-signed
>> message in one step: I'd have to physically hash, combine, re-hash and
>> compute the results, and then compare that against the signature ('b'
>> tag) decrypted with the public-key, all manually - and that's not a
>> simple task without the right tools (most of which barely exist on
>> Windows in a form that can be played with easily).
>
> And probably not worth the effort.

It would be a useful tool for a future incident, though. I shall keep
looking, just in case. There are a number of Base64 encoder/decoder
programs, and some toys that allow you to 'play' with RSA key generation
and using them to sign short messages, but nothing that allows actual
'DKIM-signed message testing' - which would actually have valid uses.
Maybe I'm just not Googling efficiently to find it.

>>
>> So - for the time being, let's assume, given that the key-strength is
>> probably too hard for cheap cracking, that it's just a dummy signature =
>> which in turn may be evidence that Demon is simply ignoring DKIM
>> signatures, after all.
>
> Seems likely now with 1024 bit keys in use but was it a month ago?

Very good question - 50-50 either way. Alas there's no way of telling
whether booking.com have changed their key in the meantime, or whether
we're looking at the same key. Some firms who have changed keys have
also changed their key location at the same time; Google haven't, though
- so clearly, it's a lottery.

In that sense, the decision on whether Demon are DKIM-checking must
therefore still be in limbo - we won't know until we get a DKIM-signed
spam or malware message that can be instantly checked against its DNS
key-repository and evaluated in terms of key-length. So far, I've not
had any DKIM-signed spam in weeks! Sod's law!

Having said that, maybe it just means they're running out of 512-bit
keyholders to rip off!

[snip]

> Thanks again for your help and your tame crypto analysist's too.

Pleasure. The tame cryptanalyst enjoys flexing his brain-muscles and
proving his worth to me in any case, and doubtless enjoys the
hero-worship in return. He's my older, smarter brother (but no, his name
is *not* Mycroft, contrary to popular belief, though he did work for
similar organisations). ;^)

TTFN
--
Neil

[MarkU]

Hear! Hear!

[Neil Jackson]

On 06/11/2012 19:47, Brian wrote:
> On 06-11-2012, Neil Jackson <ja...@techno.demon.co.uk.invalid> wrote:
>
>> So - for the time being, let's assume, given that the key-strength is
>> probably too hard for cheap cracking, that it's just a dummy signature =
>> which in turn may be evidence that Demon is simply ignoring DKIM
>> signatures, after all.
>
> Ok, we will assume that.

Maybe best not to, after all. After further consideration and
discussions with Martin, it's perfectly possible that the Booking.com
DKIM keys validated correctly at the time, and may have been
'weak/compromised keys' back in August when the emails we were testing
actually arrived in his mailbox. In the intervening time, it's
*possible* that the keys have been changed in-situ for stronger ones,
thus giving the impression that key-theft isn't possible *now*. However,
we can't be sure of their state *in the past*, so we have to now hold
off from the assumption that Demon is ignoring DKIM. It might well be
verifying DKIM sigs, and verified the ones back in August just fine.

Of course, given that Demon don't appear to write *anything* (positive
or negative) about the quality of DK/DKIM signatures in messages it
passes on, it's still highly likely they're ignoring them completely,
but we can't be certain.

>
>> If so, it's mighty funny how they put so much stead in SPF, and so
>> little in DKIM. IMHO, both are flawed, but it seems churlish to respect
>> one so vehemently, and yet completely ignore the other. And to do all
>> that whilst ignoring the good-old, well-proven RBL IP-address lookups
>> really does seem naíve - given that that step alone would probably have
>> nuked 99% of these booking.com malware-zip spams right off the bat.
>
> Who knows what is going on?

Inty, possibly, have part of the picture. I'm not wholly convinced that
Demon knows totally what's happening, now they have outsourced virtually
everything. We users, meanwhile, are trying to determine what's going
on, but it is a bit of a game of shadows, Sherlock style. Quality data
is limited; hypothesis testing takes time. Getting Demon to acknowledge
or admit certain factors or processes in use is equally hard, it seems.

>
> As for nuking mail addressed to this domain - I don't want it to happen.
> 0% nuking is my desire. I want that 99%, Why do you want to deprive me
> of it? Is it for my good or your good? I couldn't care less whether
> Demon use SPF, DKIM or RBL. Just give me the choice to opt out of email
> censoring. I can deal with my own mail. If anyone wants Demon's concept
> of what is acceptable mail they can have it as far as I am concerned.
> Just don't give it to me.

Were you aware that previously (ie pre-migration) the Cloudmark system
was in use, and your email was routinely 'spam-censored'? Did this
bother you too, or had you managed to opt-out of that? As part of that
process, the RBL IP-lookup lists were in regular use, AFAIK, similarly
blocking mail as spam.

I appreciate your desire for total non-censorship, and (as far as DKIM
and SPF are concerned at least) I share it. But the RBLs have, for the
most part (for me), worked very well in terms of reducing the amount of
garbage I needlessly download only to have my mailserver automatically
delete it (based on the self-same RBL tests plus SpamAssassin
heuristics, for the most part) - so in that regard, I don't have big
issue with the RBL nukage. There have been times (during targeted
spam-floods or joe-job attempts) when having it nuked 'further up the
pipe' (and most-importantly, *reliably so*) have saved me downloading
huge quantities of mail which would have otherwise eaten up large
portions of my monthly download limit.

So, I have a slight leaning towards 'anti-spam' that actually works well
- in terms of being targeted well, using *reliable* sources or
algorithms that result in minimal false-positives and maximal
spam-removal. But of course I appreciate not everyone enjoyed having
Cloudmark in place when it first arrived, simply because it was 'a
censorship risk' (though equally, those who found their Turnpikes or
Outlooks filled to the brim with 30,000 spams a day, all requiring
manual deletion, didn't enjoy the flipside of 'non-censorship' much
either, which is why Cloudmark arrived in the first place!). I grew to
like Cloudmark (as implemented pre-migration) simply because it worked,
and the instances of false-positives were very, very small overall (in
my experience at least).

Certainly I think we're all generally agreed that SPF is an abhorrence
for precisely the opposite reasons - it generates large numbers of false
positives which are not flagged or signalled apparently at all to either
end (despite what Demon claim), and it's open to misconfiguration by
genuine users/admins in such a way that can lose vast quantities of
genuine mail silently. And from an anti-hack/anti-spam point of view,
SPF simply doesn't work, and can actually be abused in such a way that
it will vouch *for* spam! Dead duck, imho.

Then there's DKIM which I'm equally disdainful of. My cryptanalyist
brother was most shocked when I explained to him that DKIM doesn't use
'certification paths' on its RSA signatures, and they're all
self-generated and unsigned by 'higher authorities'. His view - just
based on that aspect alone - was that DKIM was automatically broken,
because a public key without proof of trust is basically worthless;
also, certification authorities would never countersign keys that were
not of the required strength called-for by the DKIM specifications
(which is what blew up last month). So, imho, DKIM is scrap-heap
technology too.

Would I wish for an inbound stream of mail that didn't run things past
at least the Spamhaus RBL? Frankly, no - because on balance it's been
extremely reliable for me over the last few years. In an ideal world,
where 'outsiders' didn't have control over how much of my download
bandwidth allotment was consumed by their unsolicited junk or
bulk-attacks, I'd say, "yeah, let it all flow in, and I'll nuke it
locally." But the reality is, I am limited by Demon's FUP as to how much
crud I can take down the pipe. Given that I don't put all that crud in,
I expect them (Demon) to keep out the crud that really *is* crud, and/or
not to have it count against my pipe-usage stats. Tis only fair. But it
does mean that their 'anti-crud' defences actually have to be *good
ones*. They were. I'm not confident they are now.

Put another way - let's suppose Demon lifted all the anti-spam barriers
completely, and over the next month, your connection took 80GB of
malware and junk, which your mailserver or local anti-spam widget
chucked straight in the bit-bucket. Would you be happy if Demon then
throttled your connection back to 128-kbit/s for the next 30 days, or
put you into a higher tariff because you'd downloaded more in the month
than the FUP allows?

Both situations are 'wrong/bad/shouldn't happen', of course - but I
suppose the question is 'which is the lesser evil?' Decent-quality
anti-spam filtering, or quantity-limited connections with throttling
and/or punishment tariffs? I don't have the answer - but given that I
don't see the FUP vanishing anytime soon, and I don't relish the idea of
trying to explain to the Bangalore Helldesk that the only reason I
FUP-breached was because I got sent 80GB of unwanted spam in a few days,
for me, some degree of *quality* anti-spam is all that's left by way of
solution. The difficult thing, as ever, is determining that the quality
is there... YMMV, of course.

TTFN
--
Neil

[Brian]

On 07-11-2012, Neil Jackson <ja...@techno.demon.co.uk.invalid> wrote:

> On 06/11/2012 19:47, Brian wrote:
>>
>> Who knows what is going on?
>
> Inty, possibly, have part of the picture. I'm not wholly convinced that
> Demon knows totally what's happening, now they have outsourced virtually
> everything. We users, meanwhile, are trying to determine what's going
> on, but it is a bit of a game of shadows, Sherlock style. Quality data
> is limited; hypothesis testing takes time. Getting Demon to acknowledge
> or admit certain factors or processes in use is equally hard, it seems.

The contributioms in recent times from you and others on this newsgroup
have been invaluable. The recent discussion on SPF was something I
appreciated and was able to act on. Thanks.

What we need is someone from Demon to pop in every now and then to
engage with us and keep us informed with trustworthy information. Let's
call her "The Devil Incarnate". I don't think it will catch on, though.

>> As for nuking mail addressed to this domain - I don't want it to happen.
>> 0% nuking is my desire. I want that 99%, Why do you want to deprive me
>> of it? Is it for my good or your good? I couldn't care less whether
>> Demon use SPF, DKIM or RBL. Just give me the choice to opt out of email
>> censoring. I can deal with my own mail. If anyone wants Demon's concept
>> of what is acceptable mail they can have it as far as I am concerned.
>> Just don't give it to me.
>
> Were you aware that previously (ie pre-migration) the Cloudmark system
> was in use, and your email was routinely 'spam-censored'? Did this
> bother you too, or had you managed to opt-out of that? As part of that
> process, the RBL IP-lookup lists were in regular use, AFAIK, similarly
> blocking mail as spam.

I was aware that Demon had spam filtering but my understanding was that
you opted into the process. Round about 2003/2004 was the last time I
looked at this. You had the facility to opt in and opt out when you felt
like it. I didn't opt in. Ever since then I have never troubled myself
to look again at the situation and haven't had any indication that
legitimate mail has been blocked.

Incidentally, I regard legimate mail as anything addressed to this
domain. Not all of it is wanted, of course, but Demon is only the post
office (as M. Muir said) and I can deal with the aftermath of their
keeping their grubby hands off my mail.

The first consequence of my mail migration a couple of weeks ago was the
destruction of the monitoring system I have for my young grandchild's
email account. The ability to forward mails to other users of my Demon
account was also a casualty. If Demon want an endorsement of their spam
filtering mechanism from me, they can have it. Whatever the defects, it
is very effective.

But, when it comes down to it, I'd much rather have me ravage my mail
than a third party do it. Which is what I am back to now. I thought I
would never be so glad as to see today that there are still people who
think non-existent users here have an interest in T-Mobile and Vodafone
and in receiving an E-CARD.

> I appreciate your desire for total non-censorship, and (as far as DKIM
> and SPF are concerned at least) I share it. But the RBLs have, for the
> most part (for me), worked very well in terms of reducing the amount of
> garbage I needlessly download only to have my mailserver automatically
> delete it (based on the self-same RBL tests plus SpamAssassin
> heuristics, for the most part) - so in that regard, I don't have big
> issue with the RBL nukage. There have been times (during targeted
> spam-floods or joe-job attempts) when having it nuked 'further up the
> pipe' (and most-importantly, *reliably so*) have saved me downloading
> huge quantities of mail which would have otherwise eaten up large
> portions of my monthly download limit.

I can agree with your sentiments on SPF and DKIM but I'm really not too
bothered in having Demon tinker with their filtering system on my
behalf. For your benefit, yes. Sorting out the mechanics of it makes
interesting reading but having it turned off for me means I can forget
about it as a factor. Actually, I do make some use of an RBL on my mail
server but I can control that. However, you have put a little doubt into
my mind whether Demon is using RBLs on my mail, so I'll have to think of
a way of testing the conjecture.

[Snip]

> Put another way - let's suppose Demon lifted all the anti-spam barriers
> completely, and over the next month, your connection took 80GB of
> malware and junk, which your mailserver or local anti-spam widget
> chucked straight in the bit-bucket. Would you be happy if Demon then
> throttled your connection back to 128-kbit/s for the next 30 days, or
> put you into a higher tariff because you'd downloaded more in the month
> than the FUP allows?

I'm not asking for or advocating a service without anti-spam defences.
Rather, I am glad they are in place so people can take advantage of them
should they choose to. My present spam folder (created just over two
years ago) has 2,232 mails and is about 50 MB. These are the ones which
my regexes didn't deal with. Most unwanted mail was deleted on the
server before downloading. How much? I don't really know, but a guess
would be about one or two GB.

So your situation is not the same as mine and my solutions may not suit
you or your situation.

> Both situations are 'wrong/bad/shouldn't happen', of course - but I
> suppose the question is 'which is the lesser evil?' Decent-quality
> anti-spam filtering, or quantity-limited connections with throttling
> and/or punishment tariffs? I don't have the answer - but given that I
> don't see the FUP vanishing anytime soon, and I don't relish the idea of
> trying to explain to the Bangalore Helldesk that the only reason I
> FUP-breached was because I got sent 80GB of unwanted spam in a few days,
> for me, some degree of *quality* anti-spam is all that's left by way of
> solution. The difficult thing, as ever, is determining that the quality
> is there... YMMV, of course.

You don't have much choice, do you? Having chosen you are now into
trusting the system you are using. This might be ok if it weren't for
the factors you alluded to earlier.

I'd rather have the choice of two goods: filtering or no filtering.
Doing it my way I know exactly what I am trusting and who is to blame if
wanted mail is deleted.

[Neil Jackson]

On 08/11/2012 20:36, Brian wrote:
> On 07-11-2012, Neil Jackson <ja...@techno.demon.co.uk.invalid> wrote:
>
>> On 06/11/2012 19:47, Brian wrote:
>>>
>>> Who knows what is going on?
>>
>> Inty, possibly, have part of the picture. I'm not wholly convinced that
>> Demon knows totally what's happening, now they have outsourced virtually
>> everything. We users, meanwhile, are trying to determine what's going
>> on, but it is a bit of a game of shadows, Sherlock style. Quality data
>> is limited; hypothesis testing takes time. Getting Demon to acknowledge
>> or admit certain factors or processes in use is equally hard, it seems.
>
> The contributioms in recent times from you and others on this newsgroup
> have been invaluable. The recent discussion on SPF was something I
> appreciated and was able to act on. Thanks.

Thanks. It's been a nice excuse to get back into demon.service after a
very long absence. It's kinda rewarding to see that there are still some
very old faces here after all these years - but sad that a lot of other
old faces have disappeared, presumably because they've finally given up
on 'New Demon'. Can't say I blame them, tbh, but it's sad all the same.
I'm on the cusp myself. They really do seem to have lost all their
previous advantages or reasons for loyalty. About the only thing keeping
me here is inertia, and the fear of change.

>
> What we need is someone from Demon to pop in every now and then to
> engage with us and keep us informed with trustworthy information. Let's
> call her "The Devil Incarnate". I don't think it will catch on, though.

I wish it would, but I am not confident that 'New Demon' are even aware
they have a USENET news-server (given that it too is outsourced now).
I'm sure if they realised, they'd kill it (not part of the
business-customer ethos, after all, is it?) I fear they have even less
likelihood of actually working out how to use it and participate in
discussions. And they probably regard the users here as being
far-too-risky in terms of embarrassment potential; they'll be thinking
"never wrestle with a chimney-sweep", as my old editor once said...

They're much more likely to stay on their appalling forum, where they
can control the debate more easily (and the buttons are bigger).

[snip]

>> Were you aware that previously (ie pre-migration) the Cloudmark system
>> was in use, and your email was routinely 'spam-censored'? Did this
>> bother you too, or had you managed to opt-out of that? As part of that
>> process, the RBL IP-lookup lists were in regular use, AFAIK, similarly
>> blocking mail as spam.
>
> I was aware that Demon had spam filtering but my understanding was that
> you opted into the process. Round about 2003/2004 was the last time I
> looked at this. You had the facility to opt in and opt out when you felt
> like it. I didn't opt in. Ever since then I have never troubled myself
> to look again at the situation and haven't had any indication that
> legitimate mail has been blocked.

I may be wrong (and probably am, tbh) but I had a feeling Cloudmark
became compulsory (or at least 'opt-out') at one stage. I may just be
misreading the perception; but I certainly got the impression from
Demon's FAQs at the time that Cloudmark filtering was done en-masse and
by default. Of course, that may just have been an impression they wanted
to convey.

>
> Incidentally, I regard legimate mail as anything addressed to this
> domain. Not all of it is wanted, of course, but Demon is only the post
> office (as M. Muir said) and I can deal with the aftermath of their
> keeping their grubby hands off my mail.

I agree - and were it not for the tricksy issue of download-limits, I
would be desirous of exactly the same setup; no filtering *at all*.

>
> The first consequence of my mail migration a couple of weeks ago was the
> destruction of the monitoring system I have for my young grandchild's
> email account. The ability to forward mails to other users of my Demon
> account was also a casualty. If Demon want an endorsement of their spam
> filtering mechanism from me, they can have it. Whatever the defects, it
> is very effective.

Depends how you measure 'effective'. In my experience, and from other
people's comments, it's effective at removing spam in the same way that
a DDT-bomb is effective at removing locusts. Trouble is, there seems to
be a high level of collateral damage; the mice, sheep, chickens, cows
and humans all seem to be 'effectively' nuked by the DDT-bomb to varying
degrees, most of which goes entirely un-noticed.

And from what I can tell, this isn't just a side-effect of SPF; it's
something to do with the core of Mail Defender Lite itself, or its
processes for determining spam. I had originally thought this was a
Microsoft offering, but on closer inspection it turns out to be an
'IntY' homegrown solution (where 'solution' is defined as a
cobbling-together of other people's technologies with some secret sauce
added in for good measure). More info on it (or at least the 'non-Lite'
version) here: http://inty.com/UK/products/defendersuite/maildefender.html

The datasheet at http://inty.com/UK/files/MDFDatasheet1.6.pdf is quite
interesting, and may give away some of the reasons for the Lite
version's ferocity. Lite appears to have no quarantine box, so anything
it filters is presumably just dead - DDT-nuked - with no capability to
recover it, or to 'teach' the system that it's actually a false
positive. Under the hood, the system says it's pretty much Cloudmark
with some wrappers (Sophos and ClamAV anti-virus programs, and something
called 'IntYScan' which is never defined or even discussed; that's the
'secret sauce', evidently). However, despite the MailDefender program
apparently utilising Cloudmark's Block Lists (ie, RBL-lookups), I have
(or had) evidence of mail arriving here via Demon which cannot possibly
have been run past Spamhaus or Spamcop's RBLs, which is frankly
ludicrous (given that Cloudmark claim to use multiple RBLs of that ilk).

Again, it may just be because we're all on the 'Lite' product, but it
would be good (and honest) to define the Lite offering in clear detail,
perhaps, and then people might be able to work out whether that's even
something they want. At the moment, it's all guesswork several stages
removed from the coalface, which is not a good situation.

For example, it's clear that we don't have any kind of 'whitelist'
capability, like the 'full' MailDefender product apparently has - so
presumably Lite doesn't have it either. Or maybe it does and Demon just
haven't made it accessible.

So - to summarise the point, I can't say it's 'effective' at stopping
spam. It stops a lot of spam, sure. It lets some 'easy ones' through,
too. And it deletes an indeterminate amount of genuine email without any
kind of capability for detecting quantities involved. To me, that's not
'effective'. Effective implies it does its job *well*, and I don't think
it does, particularly. The same result could probably be achieved by
nuking every third email at random or stopping everything that didn't
have a sender IP originating in the UK or USA. (I am being facetious and
don't genuinely believe that, but you get the point I'm trying to make,
I'm sure).

>
> But, when it comes down to it, I'd much rather have me ravage my mail
> than a third party do it. Which is what I am back to now. I thought I
> would never be so glad as to see today that there are still people who
> think non-existent users here have an interest in T-Mobile and Vodafone
> and in receiving an E-CARD.

So have you found a way of getting out of the Mail Defender Lite loop
then? If so, I'm interested!

>
>> I appreciate your desire for total non-censorship, and (as far as DKIM
>> and SPF are concerned at least) I share it. But the RBLs have, for the
>> most part (for me), worked very well in terms of reducing the amount of
>> garbage I needlessly download only to have my mailserver automatically
>> delete it (based on the self-same RBL tests plus SpamAssassin
>> heuristics, for the most part) - so in that regard, I don't have big
>> issue with the RBL nukage. There have been times (during targeted
>> spam-floods or joe-job attempts) when having it nuked 'further up the
>> pipe' (and most-importantly, *reliably so*) have saved me downloading
>> huge quantities of mail which would have otherwise eaten up large
>> portions of my monthly download limit.
>
> I can agree with your sentiments on SPF and DKIM but I'm really not too
> bothered in having Demon tinker with their filtering system on my
> behalf. For your benefit, yes. Sorting out the mechanics of it makes
> interesting reading but having it turned off for me means I can forget
> about it as a factor. Actually, I do make some use of an RBL on my mail
> server but I can control that. However, you have put a little doubt into
> my mind whether Demon is using RBLs on my mail, so I'll have to think of
> a way of testing the conjecture.

I have SPF off too - I would not want it anywhere near my incoming mail,
as it's a complete waste of time. Classic 'Emperor's New Clothes'
syndrome, and a lot of big names that really ought to know better are
currently making bloody great fools of themselves by relying on it so
heavily (and dropping their guard in other areas, such as heuristics and
RBLing). I have lost count of the number of blue-chip companies that
have effectively 'denounced' their own CEO's home-sent emails or
forgotten an outsource or satellite office's mailsystem and have thereby
ensured all their email vanishes into an SPF-checked ether. I have yet
to actually receive some 'SPF-vouched' spam, but I know it's out there -
the technology to make it happen is childsplay.

As for the RBL situation, I'm unsure of exactly how much, if any,
RBL-checking is being done on IntY's Mail Defender Lite. As I said, I've
had email here which purports to have been through the rest of the MDL
system (except SPF) and which clearly has 'received' headers in it that
stink of blacklisted IPs. If Cloudmark really *was* RBL-checking
everything on their 'superset RBL list', then it *would* have found
them; but they still arrived here, so something is 'at odds'.

For all I know, Demon have gone back to IntY and cracked heads, or maybe
it's just been ignored - I've not had an obvious RBL-hit spam arrive for
a few days, and I haven't got time to check logs every day, so I have to
wait for one to end up in my spambox at an 'intermediate' level of
offence (the really hot ones get nuked by my own mailserver). All in
all, it's too much work to expect a customer to be verifying the quality
of the mail-feed; and as you rightly say, maybe it's better to let the
customer choose whether any sort of filtering is required at all.

>
> [Snip]
>
>> Put another way - let's suppose Demon lifted all the anti-spam barriers
>> completely, and over the next month, your connection took 80GB of
>> malware and junk, which your mailserver or local anti-spam widget
>> chucked straight in the bit-bucket. Would you be happy if Demon then
>> throttled your connection back to 128-kbit/s for the next 30 days, or
>> put you into a higher tariff because you'd downloaded more in the month
>> than the FUP allows?
>
> I'm not asking for or advocating a service without anti-spam defences.
> Rather, I am glad they are in place so people can take advantage of them
> should they choose to. My present spam folder (created just over two
> years ago) has 2,232 mails and is about 50 MB. These are the ones which
> my regexes didn't deal with. Most unwanted mail was deleted on the
> server before downloading. How much? I don't really know, but a guess
> would be about one or two GB.

This piqued my curiousity - what's your mechanism for detecting spam in
Demon's mailboxes PRIOR to downloading it? I had considered trying to
set something up to use the POP3 'TOP' command to pull down the headers,
and then scan them for RBL-obviousness and/or other spammage factors
that could be gleaned from headers - but in practice, it's not usually
worth it. Most spams these days consist of a couple of lines of body,
and the header IS pretty much the bulk of things. So TOPping doesn't
really save much download-bandwidth at all. Phishing scams and malware
*do* tend to have a body larger than headers, due to extensive bodies
that are attempting to look like bank, travel-agent, or courier
notification, or have a zip-file of binary 'executable-jpeg' junk, so in
those cases, TOPping might save a bit of bandwidth if a hot RBL IP also
happens to coincide - but the truth is, the content part can only be
malware scanned once you've got it down locally, so ultimately, you'll
be *increasing* the amount of bandwidth involved in taking down and
testing such messages (one fetch for the TOP, and if it passes, another
fetch for the full message, only to detect a Trojan in it and kill it
locally).

Given that download bandwidth is FUPed, I felt I had no choice but to
let Demon take the initiative and (if they did it well) rely on them to
filter; it was anathema to potentially pay extra to filter this myself
(insofar as a spam-tide might cost me extra by causing a FUP breach -
and in days of 'pre-Cloudmark' yore I did indeed have an instance which
might well have gone over that limit).

>
> So your situation is not the same as mine and my solutions may not suit
> you or your situation.

Absolutely. Do understand I would not inflict *ANY* kind of filtering
upon you if you didn't wish it, and I'd fight for your right to have an
unfettered, unfiltered connection if you so chose it. That's a given.

I was just curious as to how (given the FUP) running totally unfiltered
was safe, in your context, and/or whether you were aware of those
issues. You clearly have a solution that I'm keen to hear about! :)

>
>> Both situations are 'wrong/bad/shouldn't happen', of course - but I
>> suppose the question is 'which is the lesser evil?' Decent-quality
>> anti-spam filtering, or quantity-limited connections with throttling
>> and/or punishment tariffs? I don't have the answer - but given that I
>> don't see the FUP vanishing anytime soon, and I don't relish the idea of
>> trying to explain to the Bangalore Helldesk that the only reason I
>> FUP-breached was because I got sent 80GB of unwanted spam in a few days,
>> for me, some degree of *quality* anti-spam is all that's left by way of
>> solution. The difficult thing, as ever, is determining that the quality
>> is there... YMMV, of course.
>
> You don't have much choice, do you? Having chosen you are now into
> trusting the system you are using. This might be ok if it weren't for
> the factors you alluded to earlier.
>
> I'd rather have the choice of two goods: filtering or no filtering.
> Doing it my way I know exactly what I am trusting and who is to blame if
> wanted mail is deleted.

I do agree. My 'choice' of using Demon's filtering is not entirely a
free choice; I feel that (given the FUP) it's a 'Devil or the deep blue
sea' kind of choice. In the days before migration, when Demon worked
directly with Cloudmark and IntY weren't involved, I had developed over
time a reasonable level of trust. Now, it is all gone. The evidence I
see indicates that IntY are not doing as good a job, are deleting more
'false positives' without so much as a word, and aren't even doing some
of the basic RBL tests that I would have done myself. Confidence is
therefore low, in this household!

But to swap back to a 'do it all here on my mailserver' world would lay
me open to a bombard attack which (although I am confident I could stop
it coming into the mailboxes) would potentially (a) saturate my
connection during the attack and (b) cost me extra cash or the
punishment of bandwidth-throttling, if Demon so desired, if the attack
was particularly protracted. Take away the FUP, and I'd go back to
'no-filtering' tomorrow! But as it stands - and even with what I know
about POP3 TOPping - I can't see how 'no-filtering' is particularly safe
(in cash/connectivity terms); all it would take is one hefty bombard,
and you're out of pocket and/or back to a 128k connection for a month -
all through no fault of your own, and at Johnny Spammer's behest.

Tricky one. Maybe we should all start campaigning for the removal of the
FUP, as well as a 'no-filtering' option, now that the
service-provider-provided mail filtering is all outsourced and proving
to be less than ideal?

TTFN
--
Neil

[Andy]

In message <JQ4ns.237505$9W6.1...@fx08.am4>, Neil Jackson
<ja...@techno.demon.co.uk.invalid> wrote
[]

>For example, it's clear that we don't have any kind of 'whitelist'
>capability, like the 'full' MailDefender product apparently has - so
>presumably Lite doesn't have it either. Or maybe it does and Demon just
>haven't made it accessible.
>

Perhaps a blacklist can be universal, while a whitelist would have to be
per-customer?

[]

[Neil Jackson]

On 09/11/2012 10:52, Andy wrote:
> In message <JQ4ns.237505$9W6.1...@fx08.am4>, Neil Jackson
> <ja...@techno.demon.co.uk.invalid> wrote
> []
>> For example, it's clear that we don't have any kind of 'whitelist'
>> capability, like the 'full' MailDefender product apparently has - so
>> presumably Lite doesn't have it either. Or maybe it does and Demon
>> just haven't made it accessible.
>>
> Perhaps a blacklist can be universal, while a whitelist would have to be
> per-customer?
>

Absolutely, Andy - the blacklist is probably Cloudmark-based (and from
what Cloudmark say, it's comprised of a superset of other RBLs, plus
their own data gathered from the 'cloud votes'). The AV portion is
probably not blacklist-based, but content-scanning (fingerprinting, and
heuristic analysis). It's possible there is some blacklist quotient in
the IntY 'secret sauce', but it's not documented so we can't tell.

With whitelisting, it's probably a given that it's 'per-user', and
therefore very likely that it's not in the 'Lite' version of Mail
Defender - but the point is, it's not properly documented, so it's hard
to tell whether we're being shortchanged by Demon, or by Inty. It's fair
to say we had no 'whitelist' scope in the days prior to migration (so
are we really being shortchanged) - but as I've said, in those days,
Demon's use of Cloudmark was so much better, and perhaps a whitelist was
less of a necessity.

The lack of a per-user quarantine area in the offering given to us is
far more of an issue, imho. Again, whether this distinction is down to
'Lite-ness' or not, is anyone's guess (because it's not documented), but
it's probably a fair guess that that's the reason we've not got it.
Given the poorer-quality filtering, a quarantine would at least enable a
Demon user to wrest their chestnuts out of the fire - perhaps only for
'borderline' cases of spammage (otherwise the quarantine buckets would
be brimming, no doubt), but even so, it'd be better than nothing.

Of course Demon will say we can purchase a full Mail Defender product
per-user if we want; but that's not fair, imho. They've replaced
punt-mail with a crappier product which defies proper analysis and which
(from the little we've been able to test) doesn't do quite as good a job
(in terms of quality, not just quantity of blockings). And if we want to
be able to rescue our mail from that new system's clutches, we can pay
extra for whitelists and quarantine boxes, presumably. That sucks. I'd
almost say it's a breach of contract, but I'm not a lawyer, so I won't.
At the very least, it's a unilateral redefinition of service level
without informed consent.

TTFN
--
Neil

[MarkU]

A quick analysis of last weeks Mail Defender Lite bounces
reveals:

Total Bounces 67
False Positives 38

This is about on par with Cloudmark but I could, and I did, turn
Cloudmark off and deal with it myself.

Mark

[Andy]

In message <f46ns.210158$lz1....@fx28.am4>, Neil Jackson
<ja...@techno.demon.co.uk.invalid> wrote
[]

>Of course Demon will say we can purchase a full Mail Defender product
>per-user if we want; but that's not fair, imho.

I don't recall that option - and there's no point in having a local
'good' Defender fed by a universal 'bad' one. You'd need to opt out of
all demoniacal defending and DIY, which I think can only be done by
changing ISP.

[Neil Jackson]

On 09/11/2012 12:02, Andy wrote:
> In message <f46ns.210158$lz1....@fx28.am4>, Neil Jackson
> <ja...@techno.demon.co.uk.invalid> wrote
> []
>> Of course Demon will say we can purchase a full Mail Defender product
>> per-user if we want; but that's not fair, imho.
>
> I don't recall that option - and there's no point in having a local
> 'good' Defender fed by a universal 'bad' one. You'd need to opt out of
> all demoniacal defending and DIY, which I think can only be done by
> changing ISP.

ISTR the option of upgrading being mentioned on a post on the Forum, but
I may have my wires crossed.

I believe the full version might mitigate the issues caused by the bad
feed (in that, by having a quarantine bin, you can pull stuff out of it,
providing you find it there, and by having a whitelist, you can
theoretically reduce its chances of being binned again).

But you're still right, I agree. Garbage in, garbage out.

I'm considering my options vis-a-vis alternative ISPs *very* carefully,
as I'm sure a lot of folks are. Trouble is, there are few that are as
good as 'old Demon' for the same price, and many, many that are far
worse than even 'new Demon'. I do cringe when I read of people leaping
for BT as a replacement. I'd sooner put my John Thomas into the hands of
a raving madman armed with a pair of scissors, to quote Blackadder. :)

Andrews and Arnold is looking as a current favourite, but I am pondering
the likely costs, if I go to their FTTC offering. My wife and I both
work from home and use net 24/7, but Demon's tools make it virtually
impossible to get a feel for how much daytime bandwidth is actually
consumed from my average 14GB/month. A&A's offering can get *very*
expensive if the balance is more towards daytime use, so it's a bit of a
plunge in the dark at the moment, until I can get better stats.

TTFN
--
Neil

[Neil Jackson]

On 09/11/2012 11:50, MarkU wrote:

> A quick analysis of last weeks Mail Defender Lite bounces
> reveals:
>
> Total Bounces 67
> False Positives 38
>
> This is about on par with Cloudmark but I could, and I did, turn
> Cloudmark off and deal with it myself.

Cool - another confirmation that Cloudmark (of old) could indeed be
turned off. Thanks Mark. Definitely means we have lost a degree of user
choice then, I agree. This opt-out should be restored.

I'm curious as to what you used to measure your Mail Defender Lite
bounces/false-positives with. Is there a stats-panel somewhere that I've
missed? This would seem crucially useful info for a user to be able to
access, if it is accurate.

Cheers
--
Neil

[Roy Brown]

In message <ui7ns.174916$Xv.8...@fx07.am4>, Neil Jackson
<ja...@techno.demon.co.uk.invalid> writing at 13:11:49 in his/her local
time opines:-

>Andrews and Arnold is looking as a current favourite, but I am
>pondering the likely costs, if I go to their FTTC offering. My wife and
>I both work from home and use net 24/7, but Demon's tools make it
>virtually impossible to get a feel for how much daytime bandwidth is
>actually consumed from my average 14GB/month. A&A's offering can get
>*very* expensive if the balance is more towards daytime use, so it's a
>bit of a plunge in the dark at the moment, until I can get better stats.

Free options for this:-
http://www.softperfect.com/products/networx/
http://www.netlimiter.com/
(Choose the free monitor option for NetLimiter)

For a more proactive approach, NetLimiter has active limiting
capabilities. Not free long-term, but you can have a free 30-day trial
of them.
--
Roy Brown 'Have nothing in your houses that you do not know to be
Kelmscott Ltd useful, or believe to be beautiful' William Morris

[Roy Brown]

In message <JQ4ns.237505$9W6.1...@fx08.am4>, Neil Jackson
<ja...@techno.demon.co.uk.invalid> writing at 10:23:33 in his/her local
time opines:-

>On 08/11/2012 20:36, Brian wrote:
>> On 07-11-2012, Neil Jackson <ja...@techno.demon.co.uk.invalid> wrote:
>>> On 06/11/2012 19:47, Brian wrote:

>[snip]

>>> Were you aware that previously (ie pre-migration) the Cloudmark system
>>> was in use, and your email was routinely 'spam-censored'? Did this
>>> bother you too, or had you managed to opt-out of that? As part of that
>>> process, the RBL IP-lookup lists were in regular use, AFAIK, similarly
>>> blocking mail as spam.

>> I was aware that Demon had spam filtering but my understanding was that
>> you opted into the process. Round about 2003/2004 was the last time I
>> looked at this. You had the facility to opt in and opt out when you felt
>> like it. I didn't opt in. Ever since then I have never troubled myself
>> to look again at the situation and haven't had any indication that
>> legitimate mail has been blocked.

>I may be wrong (and probably am, tbh) but I had a feeling Cloudmark
>became compulsory (or at least 'opt-out') at one stage. I may just be
>misreading the perception; but I certainly got the impression from
>Demon's FAQs at the time that Cloudmark filtering was done en-masse and
>by default. Of course, that may just have been an impression they
>wanted to convey.

Demon put everyone on Cloudmark by default, and you had to opt out if
you wanted to do your own spam filtering.

The general view was that such spam filtering was essential to stop
Demon being swamped by the stuff, and that anyone who wasn't aware
enough to know the pros and cons of spam filtering might never choose to
opt in, thus defeating the object from Demon's point of view.

So they made it opt-out.

But it's simply inexcusable that you can't opt out of Mail Defender Lite
if you want to, and I'd guess that if you made enough fuss in the forum,
Demon would back off from this just as they've backed off universal SPF
checking.

[Neil Jackson]

On 09/11/2012 13:39, Roy Brown wrote:
> In message <ui7ns.174916$Xv.8...@fx07.am4>, Neil Jackson
> <ja...@techno.demon.co.uk.invalid> writing at 13:11:49 in his/her local
> time opines:-
>
>> Andrews and Arnold is looking as a current favourite, but I am
>> pondering the likely costs, if I go to their FTTC offering. My wife
>> and I both work from home and use net 24/7, but Demon's tools make it
>> virtually impossible to get a feel for how much daytime bandwidth is
>> actually consumed from my average 14GB/month. A&A's offering can get
>> *very* expensive if the balance is more towards daytime use, so it's a
>> bit of a plunge in the dark at the moment, until I can get better stats.
>
> Free options for this:-
> http://www.softperfect.com/products/networx/
> http://www.netlimiter.com/
> (Choose the free monitor option for NetLimiter)
>
> For a more proactive approach, NetLimiter has active limiting
> capabilities. Not free long-term, but you can have a free 30-day trial
> of them.

Thanks for the tips, Roy - I'd seen neither of those before... but
cursory inspection of them indicate that they're a 'per-computer'
software, so no use to me. Without giving too much away about my
internal topography, I have six or seven individual PCs, several
smartphone users, a smart TV, gaming console and internet-enabled
PVR/digibox - all of which are either on network spurs, the
common-backbone LAN switch, or WiFi connections straight to the router -
depending on where they are in the building. And yes, despite this
sounding like a mini-NASA, it's just a domestic environment, albeit it
with a couple of telecommuters in it!

What I'd really need is a solution that interrogated my Demon-supplied
ADSL modem/router (Thomson TG585), and I have tried a number of things
that operate on it via telnet, but it is pretty lame, tbh. It won't do
SNMP or even Syslog, which complicates matters a tad. Until now, it's
not been *that* important to achieve full 'time-bandwidth' awareness,
but certainly I don't think I'd be wise to move to A&A until I'd
assessed this properly - which in itself brings further inertia!

Thanks for the heads up, anyway...
--
Neil

[Neil Jackson]

Thanks Roy. That tallies with what I (vaguely) remember. I think after
some discussions with Richard Clayton I was generally of the opinion
that Cloudmark was 'worth a spin', and the experience of it over time
satisfied me that it was basically 'more good than harm'.

At least, the way it was previously implemented. Not sure about now...

>
> But it's simply inexcusable that you can't opt out of Mail Defender Lite
> if you want to, and I'd guess that if you made enough fuss in the forum,
> Demon would back off from this just as they've backed off universal SPF
> checking.

Yep, that's an option. Perhaps I'll start banging that drum after I've
made some headway on the header-rewriting fiasco that's currently my
biggest bugbear.

Cheers
--
Neil

[Jim Crowther]

In demon.service, on Fri, 9 Nov 2012 14:38:48, Neil Jackson wrote:

>Until now, it's not been *that* important to achieve full
>'time-bandwidth' awareness, but certainly I don't think I'd be wise to
>move to A&A until I'd assessed this properly - which in itself brings
>further inertia!

This household does loads of email/web browsing etc during 9-18:00 M-F,
and rarely gets near the A&A '5 Unit' tariff that I've chosen to be on.
Last two months have been an exception, but still didn't go over any
cost limits - you're allowed up to your tariff again in over-usage.
Here's a snapshot:


Billing period 01 Oct 2012 to 31 Oct 2012 Units
------------------------------------------------------------------------
Over usage from previous month 0.29
------------------------------------------------------------------------
This month Bytes Rate Units
21CN daytime (09-18 M-F) 9,140,084,912 2½GB 3.66
21CN evening (18-24 M-F) 22,234,522,442 50GB 0.44
21CN night (00-09 M-F) 7,228,331,030 50GB 0.14
21CN weekend 26,409,090,245 50GB 0.53
21CN night special 21,805,534,666 1TB 0.02

Plus excess usage from previous month 0.29
Units in the month 5.08
------------------------------------------------------------------------
Allowance calculation
Monthly tariff 5.00
------------------------------------------------------------------------
Carried over to next month
Total allowance 5.00
Total usage 5.08
Carried over usage 0.08

Not only that, but you get hourly stats for your usage, plus a graph of
your connectivity etc. All in all, it's very comprehensive monitoring.
With ~40Mbps FTTC, I'm a *very* happy customer.

--
Jim Crowther

[John Hall]

In article <k7iqsl$npj$1...@dont-email.me>,

MarkU <sp...@invalid.invalid> writes:
>A quick analysis of last weeks Mail Defender Lite bounces
>reveals:
>
>Total Bounces 67
>False Positives 38
>
>This is about on par with Cloudmark but I could, and I did, turn
>Cloudmark off and deal with it myself.

That seems like an alarmingly high level of false positives. To put it
in perspective, how many non-spam messages got through to you?
--
John Hall

"The beatings will continue until morale improves."
Attributed to the Commander of Japan's Submarine Forces in WW2

[John Hall]

In article <ui7ns.174916$Xv.8...@fx07.am4>,

Neil Jackson <ja...@techno.demon.co.uk.invalid> writes:
>On 09/11/2012 12:02, Andy wrote:
>> In message <f46ns.210158$lz1....@fx28.am4>, Neil Jackson
>> <ja...@techno.demon.co.uk.invalid> wrote
>> []
>>> Of course Demon will say we can purchase a full Mail Defender product
>>> per-user if we want; but that's not fair, imho.
>>
>> I don't recall that option - and there's no point in having a local
>> 'good' Defender fed by a universal 'bad' one. You'd need to opt out of
>> all demoniacal defending and DIY, which I think can only be done by
>> changing ISP.
>
>ISTR the option of upgrading being mentioned on a post on the
>Forum, but I may have my wires crossed.

<snip>

I'm sure you're right. In fact I think there may even be an option for
signing up to the full version somewhere if you login to your email
account on the web. Of course, it'll cost you.

[John Hall]

In article <JQ4ns.237505$9W6.1...@fx08.am4>,

Neil Jackson <ja...@techno.demon.co.uk.invalid> writes:
>The datasheet at http://inty.com/UK/files/MDFDatasheet1.6.pdf is
>quite interesting, and may give away some of the reasons for the
>Lite version's ferocity. Lite appears to have no quarantine box, so
>anything it filters is presumably just dead - DDT-nuked - with no
>capability to recover it, or to 'teach' the system that it's actually a
>false positive.

Just before I was migrated, I arranged for all my email to jhall.co.uk
to be forwarded to gmail as well as to Demon, because I was worried
about SPF. As it turned out, Demon made it possible to opt out of SPF
just after I was migrated, but I'm still glad that I have the gmail
alternative. Unlike Mail Defender Lite, there is a (supposed) spam
quarantine box, from which I can move non-spam items to the inbox (from
where I can then download it) by marking it as non-spam. And doing this
seems to usefully teach the system. Of course gmail's other great
advantage is that it is free.

I've noticed only an occasional item that Mail Defender Lite has zapped
when it shouldn't, but even at that level it is worrying. I believe that
it is now possible to get Mail Defender Lite turned off, the procedure
for asking for this being the same as with SPF. However, although spam
levels currently seem to be low, I'm reluctant to do that for fear that
it will increase back to the hundreds a day level before long.

[John Hall]

In article <zXZhawEw...@jhall.demon.co.uk.invalid>,

John Hall <nospam...@jhall.co.uk> writes:
>Just before I was migrated, I arranged for all my email to jhall.co.uk
>to be forwarded to gmail as well as to Demon, because I was worried
>about SPF. As it turned out, Demon made it possible to opt out of SPF
>just after I was migrated, but I'm still glad that I have the gmail
>alternative. Unlike Mail Defender Lite, there is a (supposed) spam
>quarantine box, from which I can move non-spam items to the inbox (from
>where I can then download it) by marking it as non-spam. And doing this
>seems to usefully teach the system. Of course gmail's other great
>advantage is that it is free.

Oh yes, one other advantage is that gmail preserves whatever is before @
in the envelope from address rather than replacing it with
"administrator".

[Brian]

On 09-11-2012, Neil Jackson <ja...@techno.demon.co.uk.invalid> wrote:

> On 08/11/2012 20:36, Brian wrote:
>>
>> I was aware that Demon had spam filtering but my understanding was that
>> you opted into the process. Round about 2003/2004 was the last time I
>> looked at this. You had the facility to opt in and opt out when you felt
>> like it. I didn't opt in. Ever since then I have never troubled myself
>> to look again at the situation and haven't had any indication that
>> legitimate mail has been blocked.
>
> I may be wrong (and probably am, tbh) but I had a feeling Cloudmark
> became compulsory (or at least 'opt-out') at one stage. I may just be
> misreading the perception; but I certainly got the impression from
> Demon's FAQs at the time that Cloudmark filtering was done en-masse and
> by default. Of course, that may just have been an impression they wanted
> to convey.

All of that may be correct, but considering I never concerned myself
with that aspect of the service I'm unaware of what has been going on in
recent years. At present, the policy adopted by Demon does appear not to
favour those people who desire an unfiltered service. One can only guess
at what the technical or commercial reasons might be, Perhaps, it is
because we are a minority set of ungrateful nuisances. Or is that
someone has decided only idiots do not want spam filtering? After all,
you only have to look around to see how many more people complain about
spam being received compared with those who bemoan not getting it.

Digging into my mail archive from December 2007, Malcolm Muir wrote
from owner-a...@demon.net:

We are pleased to announce that from Monday 3rd December it will
be possible for customers to submit reports of spam that they
have received for consideration in tuning our spam filters.

Not all email that customers consider to be spam will be included
in future filtering as there are strict rules in place to ensure
that only email that passes relevant tests can be considered spam.

In order to submit a valid report you must ensure that:

* the spam filtering service is enabled on your account. You can
enable the spam filtering service at any time by logging into
the WebPassword control panel
<https://www.password.uk.demon.net/>,
clicking on the 'Mail' button at the top and then ticking the
Anti-spam box.

There is an implication that, at that time at least, one needed to opt
in to the spam filtering service. But it's a minor point, and now
history.

So off I went to https://www.password.uk.demon.net/, where I found the
section

Anti-spam:
Setting this option enables detection and rejection of spam.

is unticked. I know I have never used the spam filtering service (not
even as a test) so, if Demon did have Cloudmark filtering as a default,
it has not been applied to my account.

It may have become the default in the past four years. But the enormous
difference between now and then is that it could be reverted.

>> But, when it comes down to it, I'd much rather have me ravage my mail
>> than a third party do it. Which is what I am back to now. I thought I
>> would never be so glad as to see today that there are still people who
>> think non-existent users here have an interest in T-Mobile and Vodafone
>> and in receiving an E-CARD.
>
> So have you found a way of getting out of the Mail Defender Lite loop
> then? If so, I'm interested!

Not knowing precisely how Mail Defender Lite works and how it is
controlled makes me wary of claiming I have escaped its evil influence
completely. As you say, it an IntY product based on a modular design
using, in the main, existing software solutions. I would aslo expect its
operation not to remain static over time.

At

http://help.demon.net/help-articles/demon-email-management-portal/

it says

MailDefender Lite provides a pre-filtering service against spam and
viruses.

Then at

http://forum.demon.net/topic/excess-spam

I can confirm there's been no downgrading etc. The "lite" service
on the new platform in terms of spam detection is essentially the
same as what we do at the moment on the current platform, just a
newer, more effective instance of it.

So a polite and firm email to newmail asking for SPF and pre-filtering
to be turned off was sent. The outcome was positive.

> Absolutely. Do understand I would not inflict *ANY* kind of filtering
> upon you if you didn't wish it, and I'd fight for your right to have an
> unfettered, unfiltered connection if you so chose it. That's a given.
>
> I was just curious as to how (given the FUP) running totally unfiltered
> was safe, in your context, and/or whether you were aware of those
> issues. You clearly have a solution that I'm keen to hear about! :)

I run mailfilter on Linux. It examines the mail headers only and deletes
acording to my rules. Anything with a To: header having a non-existent
user, for example, goes. That accounts for at least 90% of unwanted
mail. Message-Ids can also be fruitfully incorporated in a rule. For
example, Message-ID: <l[20 is not valid.

It is time-consuming to set up at the beginning but there is some
satisfaction in such mails not having to be processed by the filters on
my machine. Doesn't catch everything, of course. But what does?

And yes. I have inadvertently deleted a few days' worth of mail!

I've never examined the bandwidth cost of implementing this scheme but,
from the amount of spam you get, it may be prohibitive for you. No
solution springs immediately to mind, but I would experiment with the
same or a similar program.

Just a thought. If you have all your users set up with an account you
could assume anything which goes into the administrator is unwanted and
not scan it.

> Tricky one. Maybe we should all start campaigning for the removal of the
> FUP, as well as a 'no-filtering' option, now that the
> service-provider-provided mail filtering is all outsourced and proving
> to be less than ideal?

"Bandwidth Trading" between Demon customers?

[Andrew Brydon]

On 06/11/2012 19:47, Brian wrote:

Thanks to idiot-proof instructions given in an earlier message in
this group I've been able to do just that, and opt out of SPF.
Many thanks to the knowledgeable folks here.

--
Andrew Brydon
Life is just the beta-version of death

[MarkU]

John Hall wrote:
> In article <JQ4ns.237505$9W6.1...@fx08.am4>,
<snip>

> I believe that it is now possible to get Mail Defender Lite
turned
> off, the procedure for asking for this being the same as with
SPF.

<snip>

Is that correct? Can someone confirm? That would save me sooo
much grief.

Mark

[MarkU]

John Hall wrote:
> In article <k7iqsl$npj$1...@dont-email.me>,
> MarkU <sp...@invalid.invalid> writes:
>> A quick analysis of last weeks Mail Defender Lite bounces
>> reveals:
>>
>> Total Bounces 67
>> False Positives 38
>>
>> This is about on par with Cloudmark but I could, and I did,
turn
>> Cloudmark off and deal with it myself.
>
> That seems like an alarmingly high level of false positives. To
put it
> in perspective, how many non-spam messages got through to you?

I don't have a figure for that without wading through the logs.
It would be in the order of hundreds.

--
Mark

[MarkU]

Our mail passes through an external spam filter on it's way to
Demon. As a result I am able to see the Mail Defender Lite
rejections in the logs. These filters are never perfect which is
why some spam managed to get through the first filter to get
bounced by Mail Defender Lite.

--
Mark

[Neil Jackson]

Thanks Mark - that's very useful to know how you were obtaining these
stats. It also confirms that Demon is at least giving SMTP rejection
errors at transaction time, rather than silently deleting the email
after acceptance (which was under discussion a while back).

I don't suppose you happened to see any IntY-end rejections that cited
SPF-validation failures, did you? I appreciate you've probably got
Demon's SPF-checking turned off now, but I'm asking just on the
off-chance. I'm still not wholly sure of how Demon/IntY is handling
SPF-hardfail rejections; Demon *say* they're 'issuing bounces' but
haven't made it clear where in the process (if at all) this is
happening; similarly some folks have reported no
feedback/failure-indication whatsoever (and certainly no separate
Demon-generated bounce-message). Gladwell, for example, don't appear to
be passing any hint that messages may have been SPF-rejected (according
to another user's experiences here).

So - if you did happen to have any evidence of a Demon/IntY-generated
SMTP 'mid-transaction' rejection citing SPF, as a result of your remote
antispam gateway, that would be very useful to see.

Incidentally - I know it doesn't prove Demon isn't using *any* RBLs, but
today I received two separate spammy emails, both of which have gone
through the entire inbound Demon chain (minus SPF-checking) and both of
which feature IP addresses that have been blacklisted by SpamCop.Net
(but not Spamhaus, it must be said). I think we can deduce from that,
that Demon/IntY and/or Cloudbase aren't considering SpamCop in their
list of reputable RBLs to check - if indeed they're checking against any
RBLs at all (though they say they are...)

Cheers again for the info - most interesting!
--
Neil

[Neil Jackson]

Thanks for this info, Jim - very useful. Apologies for the late response
- I was waiting until I had a chance to go number-crunching at the A&A
website to see what those figures equated to in terms of cash.

Am I right in thinking that a 5-unit tariff on FTTC costs you in the
order of 41.70 a month (inc VAT)? That's what I seemed to get up - using
a 10GB/month day-rate and a 50GB/month weekend/night rate. I suppose
bandwidth-wise, 60GB is comparable with what Demon allow, but of course,
for me, it's the daytime split that makes it expensive. I'm not sure if
I could justify a more-than-doubling of my connection-costs just on the
basis of FTTC (which would be the only effective difference really -
discounting the ill-effects of Demon's recently poor service-level
offerings, of course).

OTOH, I was figuring I *might* just about be able to scrape by on a
3-unit tarriff (which would give me 5GB/month daytime FTTC usage for
£33.90) - but without knowing what my current Demon daytime averages
might be, it's hard to know whether this would be a ridiculous limit or
not. Thank you Demon, for making it so hard to judge, eh? :)

I will find a way.... ;-)

Thanks again for the info, Jim. Much appreciated.
--
Neil

[John Hall]

In article <k7qqe3$ior$1...@dont-email.me>,

Thanks. So 38 false positives would be a non-negligible proportion of
the non-spam email sent to you.

[John Hall]

In article <k7qokm$8b8$1...@dont-email.me>,

I think I saw someone say that in a thread on Demon's web forum, but I
can't guarantee that my memory is correct.

[Jim Crowther]

In demon.service, on Mon, 12 Nov 2012 17:06:12, Neil Jackson wrote:

>Am I right in thinking that a 5-unit tariff on FTTC costs you in the
>order of 41.70 a month (inc VAT)? That's what I seemed to get up -
>using a 10GB/month day-rate and a 50GB/month weekend/night rate. I
>suppose bandwidth-wise, 60GB is comparable with what Demon allow, but
>of course, for me, it's the daytime split that makes it expensive. I'm
>not sure if I could justify a more-than-doubling of my connection-costs
>just on the basis of FTTC (which would be the only effective difference
>really - discounting the ill-effects of Demon's recently poor
>service-level offerings, of course).

Yes, I pay about GBP42 pm - but for me it's worth it for the completely
unfiltered feed, having my own /29 IPv4 block, fully configurable zone
file, and all the other things that even back in the day Demon couldn't
or wouldn't provide.

Not for everyone granted, but just the ticket for the more savvy
Demonites who are getting fed up with the continuing mail fiasco.

--
Jim Crowther

[Tony]

<http://forum.demon.net/topic/turn-off-mail-defender> says Demon will
"investigate each customer issue on a case by case basis".

--
Tony

[MarkU]

I didn't see anything SPF related but then I've already had SPF
checking turned off.

--
Mark

[MarkU]

Thanks Tony. I'll investigate.

--
Mark

[Neil Jackson]

On 13/11/2012 11:15, MarkU wrote:
> Neil Jackson wrote:

>> I don't suppose you happened to see any IntY-end rejections
> that cited
>> SPF-validation failures, did you? I appreciate you've probably
> got
>> Demon's SPF-checking turned off now, but I'm asking just on the
>> off-chance.

[snip]

> I didn't see anything SPF related but then I've already had SPF
> checking turned off.

The jury's still out, then, as to Demon's SPF-notification behaviour!
Thanks anyway - I did figure it was a long-shot... any log you would've
had, would've been from some time ago, and unlikely to have been kept.
But it was worth an ask. :)

Cheers
--
Neil

[Brian]

Nice to know the right to receive the mail you want to receive is
subject to an investigation. And all without your knowing a single
criterion which applies to judging the case submitted.

The quoted URL also has

". . . . and then determine the best solution for you,"

Sounds ominous.


--
Brian