Maildefender Lite

[News]

Stupid question, probably, but is there any way I can see what, if
anything, has been blocked by maildefender lite?

Thank you.
--
Graeme

[Neil Jackson]

On 14/11/2012 21:18, News wrote:
>
> Stupid question, probably, but is there any way I can see what, if
> anything, has been blocked by maildefender lite?

From the web-portal, no. From your email inbox, no.

One user who has a separate, paid-for, anti-spam service that receives
the Demon-bound emails in the first instance, filters them, and then
sends them on to Demon (via SMTP), receives a certain amount of logging
information from that anti-spam service, which he can then decipher and
determine at least some of what Demon's system has blocked. But that's
not going to be something many of us can or want to do.

So the short answer is no. Sorry.

Apparently Demon will consider requests to be removed from the
MailDefender Lite 'chain', on a case by case basis, if asked, but
they're not making it easy. I would imagine cases of the ilk "I'll
blimmin' well leave Demon if you require me to use this crap" will
probably be the cases that get taken off it, but that's just a guess,
based on standard rules of corporate wallet-protection! :)

I'm seriously considering being removed from it myself (at least while
there is no 'quarantine bucket' or log of rejections for us to peruse) -
but the only thing causing me to hesitate is that fact that, with an
unfiltered feed, it would mean some happy-go-crazy spammer would then
have the scope to flood my connection with spam that would count against
my monthly download bandwidth limit, which imho, is simply not fair.
--
Neil

[News]

In message <Kj3ps.224071$g62.1...@fx06.am4>, Neil Jackson
<ja...@techno.demon.co.uk.invalid> writes

>On 14/11/2012 21:18, News wrote:
>>
>> Stupid question, probably, but is there any way I can see what, if
>> anything, has been blocked by maildefender lite?
>
>From the web-portal, no. From your email inbox, no.

Thank you Neil, for both answer and explanation. It seems very, very
odd to me that my incoming mail can be filtered, yet I cannot see what
has been filtered.

Something odd is happening, but I'm not sure what. Most of my incoming
mail is addressed to something at binnsroad dot net, where something
could be anything from amazon to zooplus. Most seem to be working, but
not all. The binnsroad net domain is managed by freeparking co uk, and
has worked well for many years. Anything at binnsroad dot net is
forwarded to my name at binnsroad demon co uk, but some names seem to be
failing. eBay suddenly stopped working yesterday, twitter has not
worked for months, and a mailing list stopped working following mail
migration. A private list, not Yahoo. All the Yahoo groups seem to be
fine.

I'm not sure what to do next.
--
Graeme

[John Hall]

In article <uAHF0WlH...@nospam.demon.co.uk>,
News <Gra...@nospam.demon.co.uk> writes:
<snip>

>Anything at binnsroad dot net is forwarded to my name at
>binnsroad demon co uk, but some names seem to be failing.

Ah, I hadn't realised that your mail was forwarded to you Demon account.
In that case, have you asked Demon to switch off SPF for you, as if not
that would have the effect of preventing mail from certain senders
reaching you.

If you haven't heard about the SPF issue, then there is a very lengthy
discussion about it on Demon's web forum at:

http://forum.demon.net/topic/new-email-server-use-of-sender-policy-framework#post-774
--
John Hall

"Whenever people agree with me I always feel I must be wrong."
Oscar Wilde

[News]

In message <stW+Z4GL...@jhall.demon.co.uk.invalid>, John Hall
<nospam...@jhall.co.uk> writes

>In article <uAHF0WlH...@nospam.demon.co.uk>,
> News <Gra...@nospam.demon.co.uk> writes:
><snip>
>>Anything at binnsroad dot net is forwarded to my name at
>>binnsroad demon co uk, but some names seem to be failing.
>
>Ah, I hadn't realised that your mail was forwarded to you Demon account.
>In that case, have you asked Demon to switch off SPF for you, as if not
>that would have the effect of preventing mail from certain senders
>reaching you.

Thanks John. Yes, I sent an e-mail to Demon earlier this week,
requesting SPF be turned off. The usual automated response, but nothing
else. I'm sure that, in another thread, there is a guide to recognising
whether or not SPF has been turned off. I'll have a search.

Having read other threads here, I wonder whether I should be setting up
additional users.
--
Graeme

[Richard Clayton]

In article <Kj3ps.224071$g62.1...@fx06.am4>, Neil Jackson <jacko@techn
o.demon.co.uk.invalid> writes

>Apparently Demon will consider requests to be removed from the
>MailDefender Lite 'chain', on a case by case basis, if asked, but
>they're not making it easy.

I expect that they are concerned that people will not realise the
implications and ask to be moved back again, creating work and ill
feeling all round.

-=-=-=-

but an anecdote ...

... it was finally my turn to be moved to the new system last Tuesday.

so I wrote to the new...@demon.net address last Saturday asking for SPF
to be turned off (and in passing I made some observations about wanting
no spam filtering [which they could easily do by pointing the MX record
at my ADSL IP address where I run my own mail server]). I also made it
clear that I understood the implications of my request.

they replied saying that the MX record could not be pointed at my ADSL,
_but_ helpfully saying that I could have either SPF turned off or spam
filtering turned off but not both -- I opted for no spam filtering.

they then wrote again saying I'd been misinformed and I could have both
turned off -- so I said "yes please" and (apart from an initial hour or
so when the spam filtering was on -- so it rejected some transactional
email from a phishing detection system! -- it's been fine ever since).

by "fine" I of course mean that it is trashing any record of the SMTP
conversation so that my email routing has to be rebuilt (no small matter
when you get (and are interested in) as much spam as I receive) and I've
now reduced the load on their systems considerably by running my own
POP3 service which creates the Received: header fields I need. viz: I am
not forwarding any email to "Demon" that I can handle completely on my
own systems, so it is only exotic email (almost all spam) that is sent
to my *.demon.co.uk domain that is messed around with.

Anyway -- the take away from the above is that it is possible to have
either or both of SPF and spam filtering disabled. You should however
know what you are doing before choosing this route.

--
richard writing to inform and not as company policy

"Assembly of Japanese bicycle require great peace of mind" quoted in ZAMM

[J. P. Gilliver (John)]

In message <ePoE1lCp...@highwayman.com>, Richard Clayton
<ric...@highwayman.com> writes:
[]

>they replied saying that the MX record could not be pointed at my ADSL,
>_but_ helpfully saying that I could have either SPF turned off or spam
>filtering turned off but not both -- I opted for no spam filtering.
>
>they then wrote again saying I'd been misinformed and I could have both
>turned off -- so I said "yes please" and (apart from an initial hour or
>so when the spam filtering was on -- so it rejected some transactional
>email from a phishing detection system! -- it's been fine ever since).

Depressing that, while under the impression that only one could be
turned off, they actually turned off the one you had _not_ requested be
turned off.
[]

>Anyway -- the take away from the above is that it is possible to have
>either or both of SPF and spam filtering disabled. You should however
>know what you are doing before choosing this route.
>

I asked (after reading some discussion here) for SPF to be turned off,
and had a confirmation that this had been done. What (in _your_ opinion
- I've read others here, which are what made me decide to ask for it) is
the _dis_advantage of having done so? I can see the obvious potential
disadvantages (for an ordinary user) of asking for spam filtering to be
turned off. (I'm glad to have that on; it was more or less not working
before migration, even though I definitely had it set to on. I don't
think I know anyone whom I consider it important that they be able to
contact me, who doesn't know other means of doing so, so I'm not worried
about false positives in the spam filtering.)
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

Diplomacy is the art of letting someone have your way.

[Brian]

On 17-11-2012, Richard Clayton <ric...@highwayman.com> wrote:

> In article <Kj3ps.224071$g62.1...@fx06.am4>, Neil Jackson <jacko@techn
> o.demon.co.uk.invalid> writes
>
>>Apparently Demon will consider requests to be removed from the
>>MailDefender Lite 'chain', on a case by case basis, if asked, but
>>they're not making it easy.
>
> I expect that they are concerned that people will not realise the
> implications and ask to be moved back again, creating work and ill
> feeling all round.

Maybe. Of course they could have a help page explaining what they see to
be the implications. Or deal with it in the same way they did on the
sdps system. However, unlike now they presumably had complete control
over that system, so were able to allow users to turn spam filtering on
and off at will.

[Snip]

> Anyway -- the take away from the above is that it is possible to have
> either or both of SPF and spam filtering disabled. You should however
> know what you are doing before choosing this route.

In the case of SPF it took about six months of pressure and meticulous
argiument before someone in the chain of command made a decision which
caused mx5 and mx6 to materialise in their present form. I'm conscious
of the fact that had my migration been a few months earlier and this
battle had not been fought I may not be here. Quite why spam filtering
can now be disabled has never been revealed but my experience is similar
to yours. When I requested it there was immediate compliance. Perhaps I
gave the impression of being sane and knowing exactly what I was doing :).

As for a Demon MX record being pointed at an ADSL IP, I thought that was
possible with Business Unlimited. It could be that I have imagined this
though.


--
Brian

[News]

In message <LCRyN$rfn5p...@soft255.demon.co.uk>, "J. P. Gilliver
(John)" <G6...@soft255.demon.co.uk> writes

>I asked (after reading some discussion here) for SPF to be turned off,
>and had a confirmation that this had been done. What (in _your_ opinion
>- I've read others here, which are what made me decide to ask for it)
>is the _dis_advantage of having done so?

I too would like an opinion, having asked Demon to turn SPF off, without
really knowing why, or the pros and cons.

--
Graeme

[Richard Clayton]

In article <LCRyN$rfn5p...@soft255.demon.co.uk>, J. P. Gilliver (John)
<G6...@soft255.demon.co.uk> writes

>In message <ePoE1lCp...@highwayman.com>, Richard Clayton
><ric...@highwayman.com> writes:
>[]
>>they replied saying that the MX record could not be pointed at my ADSL,
>>_but_ helpfully saying that I could have either SPF turned off or spam
>>filtering turned off but not both -- I opted for no spam filtering.
>>
>>they then wrote again saying I'd been misinformed and I could have both
>>turned off -- so I said "yes please" and (apart from an initial hour or
>>so when the spam filtering was on -- so it rejected some transactional
>>email from a phishing detection system! -- it's been fine ever since).
>
>Depressing that, while under the impression that only one could be
>turned off, they actually turned off the one you had _not_ requested be
>turned off.

I don't see how you can draw that conclusion from what I wrote :(

>I asked (after reading some discussion here) for SPF to be turned off,
>and had a confirmation that this had been done. What (in _your_ opinion
>- I've read others here, which are what made me decide to ask for it) is
>the _dis_advantage of having done so?

You may receive emails claiming to be from PayPal which are not in fact
from PayPal --- since I do research into phishing and other types of
ecrime I see this as an advantage (I get to see more samples), however
for most people this would be a disadvantage and possibly an expensive
(or at least inconvenient whilst you argued about liability) occurrence

[Andy]

In message <xPfPF4P6...@highwayman.com>, Richard Clayton
<ric...@highwayman.com> wrote

>In article <LCRyN$rfn5p...@soft255.demon.co.uk>, J. P. Gilliver (John)
><G6...@soft255.demon.co.uk> writes
>

[]

>>I asked (after reading some discussion here) for SPF to be turned off,
>>and had a confirmation that this had been done. What (in _your_ opinion
>>- I've read others here, which are what made me decide to ask for it) is
>>the _dis_advantage of having done so?
>
>You may receive emails claiming to be from PayPal which are not in fact
>from PayPal --- since I do research into phishing and other types of
>ecrime I see this as an advantage (I get to see more samples), however
>for most people this would be a disadvantage and possibly an expensive
>(or at least inconvenient whilst you argued about liability) occurrence
>

I have recently asked for SPF to be turned off, but have for quite some
time now (months, probably years) received fake Paypal emails.
--
Andy Taylor [Editor, Austrian Philatelic Society].
Visit <URL:http://www.austrianphilately.com>

[J. P. Gilliver (John)]

In message <xPfPF4P6...@highwayman.com>, Richard Clayton

<ric...@highwayman.com> writes:
>In article <LCRyN$rfn5p...@soft255.demon.co.uk>, J. P. Gilliver (John)
><G6...@soft255.demon.co.uk> writes
>
>>In message <ePoE1lCp...@highwayman.com>, Richard Clayton
>><ric...@highwayman.com> writes:
>>[]
>>>they replied saying that the MX record could not be pointed at my ADSL,
>>>_but_ helpfully saying that I could have either SPF turned off or spam
>>>filtering turned off but not both -- I opted for no spam filtering.

It was initially said you could have no SPF or no spam filtering. You

opted for no spam filtering.

>>>
>>>they then wrote again saying I'd been misinformed and I could have both
>>>turned off -- so I said "yes please" and (apart from an initial hour or
>>>so when the spam filtering was on -- so it rejected some transactional

Spam filtering was on, despite you requesting otherwise.

>>>email from a phishing detection system! -- it's been fine ever since).
>>
>>Depressing that, while under the impression that only one could be
>>turned off, they actually turned off the one you had _not_ requested be
>>turned off.
>
>I don't see how you can draw that conclusion from what I wrote :(

I hope I've made it clearer now how I drew that conclusion. However, I
can see that that could have been ("initial hour") before your request
was implemented.

>
>>I asked (after reading some discussion here) for SPF to be turned off,
>>and had a confirmation that this had been done. What (in _your_ opinion
>>- I've read others here, which are what made me decide to ask for it) is
>>the _dis_advantage of having done so?
>
>You may receive emails claiming to be from PayPal which are not in fact
>from PayPal --- since I do research into phishing and other types of
>ecrime I see this as an advantage (I get to see more samples), however
>for most people this would be a disadvantage and possibly an expensive
>(or at least inconvenient whilst you argued about liability) occurrence
>

Thanks, understood. I _hope_ I could still identify such an email, but I
understand the risk. None so far, AFAIK (-:!

(Or rather, having just read Andy's post - none that I _haven't_
identified, I hope. I too have been receiving fake Paypal emails for
years.)

--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

So, Heresy be damned (well, it would be, wouldn't it?).
Radio Times 24-30 July 2010 (page 24)

[Richard Clayton]

In article <qk+OBHBi...@kitzbuhel.demon.co.uk>, Andy
<an...@kitzbuhel.demon.co.uk> writes

>In message <xPfPF4P6...@highwayman.com>, Richard Clayton
><ric...@highwayman.com> wrote

>>You may receive emails claiming to be from PayPal which are not in fact
>>from PayPal --- since I do research into phishing and other types of
>>ecrime I see this as an advantage (I get to see more samples), however
>>for most people this would be a disadvantage and possibly an expensive
>>(or at least inconvenient whilst you argued about liability) occurrence
>>
>I have recently asked for SPF to be turned off, but have for quite some
>time now (months, probably years) received fake Paypal emails.

there is a difference between "fake" and "claiming to be from PayPal"

I expect the "fake" ones came from paypall.com or similar

[Andy]

In message <+escxQQ3...@highwayman.com>, Richard Clayton

<ric...@highwayman.com> wrote
>In article <qk+OBHBi...@kitzbuhel.demon.co.uk>, Andy
><an...@kitzbuhel.demon.co.uk> writes
>
>>In message <xPfPF4P6...@highwayman.com>, Richard Clayton
>><ric...@highwayman.com> wrote
>
>>>You may receive emails claiming to be from PayPal which are not in fact
>>>from PayPal --- since I do research into phishing and other types of
>>>ecrime I see this as an advantage (I get to see more samples), however
>>>for most people this would be a disadvantage and possibly an expensive
>>>(or at least inconvenient whilst you argued about liability) occurrence
>>>
>>I have recently asked for SPF to be turned off, but have for quite some
>>time now (months, probably years) received fake Paypal emails.
>
>there is a difference between "fake" and "claiming to be from PayPal"
>
>I expect the "fake" ones came from paypall.com or similar
>

I've deleted them now so can't check. If I get another while the topic
is still live I'll post it.

[Neil Jackson]

On 18/11/2012 09:40, Richard Clayton wrote:
> In article <LCRyN$rfn5p...@soft255.demon.co.uk>, J. P. Gilliver (John)
> <G6...@soft255.demon.co.uk> writes

> [snip]

>> I asked (after reading some discussion here) for SPF to be turned off,
>> and had a confirmation that this had been done. What (in _your_ opinion
>> - I've read others here, which are what made me decide to ask for it) is
>> the _dis_advantage of having done so?
>
> You may receive emails claiming to be from PayPal which are not in fact
> from PayPal --- since I do research into phishing and other types of
> ecrime I see this as an advantage (I get to see more samples), however
> for most people this would be a disadvantage and possibly an expensive
> (or at least inconvenient whilst you argued about liability) occurrence

I feel a compulsion to elaborate on Richard's example, because two
laymens' interpretations of "emails claiming to be from PayPal" can be
vastly different. A lot of devil is hidden in the detail of SMTP.

At the risk of seeming rude (by correcting/nit-picking Richard's post) I
think Richard actually means "You may receive emails *that have SMTP
'MAIL FROM:' envelope headers* claiming to be from PayPal which are not
in fact from PayPal". (And of course, 'PayPal' would be any domain that
(a) used SPF records in its DNS and (b) had them set to 'hardfail'.
Amazon.com and Twitter.com are or were both in that camp too, when last
I looked).

The reality is that even with SPF, it's still perfectly possible to
receive emails which (to the uninitiated layman) still LOOK like emails
from PayPal: the 'From' address at the top of the email program's
message window says 'ser...@paypal.com' and that's enough to convince
them (assuming they don't spot a clue elsewhere, or look at the message
headers in detail - and let's face it, the people who get caught, don't
do this).

SPF does NOT validate 'internal' message-header 'From' or 'Reply-To' or
'Sender' addresses in the slightest. It *only* checks SMTP 'MAIL FROM:'
envelope headers (which may or may not be copied into the message
headers as 'Return-Path:' headers, depending on the mailserver accepting
the message, so you may not even see them, depending on how they arrived).

Unfortunately, given that plenty of layman are (apparently) tricked by
the most ridiculous-looking phishing attempts, with missing or broken
PayPal logos; poor spelling; a failure to address them by their
registered, real name; links to websites that are clearly
differently-labelled than their anchor locations and which ask for
things that PayPal would never ask for, and aren't even on the
PayPal.com domain, the use of SPF is only ever going to be of partial
value, assuming it even worked properly!

Given that it fails totally in the case of forwarded messages (by
causing the deletion of all LEGITIMATE, GENUINE email from a
'SPF-hardfail' sender-domain),

...and given that spoofed mail can be sent from throwaway domains which
use SPF 'trust-everything' catch-all settings at the SMTP 'MAIL FROM'
envelope stage, and contain spoofed 'From/Reply-To/Sender' headers
'in-message', yet contain spammy or phishy message content that is now
disproportionately more 'trusted' (on some servers) by virtue of the
successful SPF validation,

...I'd say SPF is a dead duck.

Unfortunately, it's currently surviving due to the 'madness of crowds'
syndrome. "A million flies can't be wrong - eat manure!" is, in essence,
the way SPF is surviving - nay, growing, even, in some quarters. It
makes me sick to my stomach that Demon have fallen for this utter, utter
crap.

At best, SPF will stop some SMTP-envelope-from spoofs, but not all by
any means, and it will never stop 'message-header' spoofs. At worst, it
will lose you some legitimate email if you have forwarded en-route from
a tertiary/vanity email address. At the very worst, if misconfigured by
the sender domain (which is increasingly commonly happening), legitimate
emails from that domain will not arrive at all, anywhere that practices
SPF validation on incoming messages. At the very, very worst, some
spammy/spoofy/phishy email will actually look 'trustworthy' by virtue of
an SPF +all catch-all setup on a spammer's sending domain.

Switching SPF off at Demon will place you at exactly the same level of
risk you were at in late 2011/early 2012, in terms of the possibility of
'spoof' phishing/malware junk arriving. However you handled it then,
you'd continue to handle it now.

Conversely, leaving SPF on, will not stop *all* phishing email arriving
'apparently' arriving from (spoofed) domains that purport to use SPF, so
the level of confidence gained from SPF is false. The mechanism of those
spoofs that continue to arrive will be slightly different, but will
still require the same degree of pre-2012 skill to detect and avoid
falling foul of, so in practice, SPF means 'business as usual' for the
phishermen. They're after the wuckfits; the solution is, 'don't be a
wuckfit!' The solution is *NOT* 'use SPF'.

My apologies again for assuming to 'correct' Richard's definition;
hopefully he/you won't mind unduly as my intentions are honourable! :)


TTFN
--
Neil

[News]

In message <aEtqs.598679$Ol2.4...@fx25.am4>, Neil Jackson
<ja...@techno.demon.co.uk.invalid> writes

<snip extremely useful information>

>The solution is *NOT* 'use SPF'.
>
>My apologies again for assuming to 'correct' Richard's definition;
>hopefully he/you won't mind unduly as my intentions are honourable! :)

Neil, thank you. I now feel that I understand the risk involved, if not
the technicalities behind it. I asked for SPF to be switched off last
week, and received a message from Demon, saying that it had been
switched off today.

Lo and behold, two series of e-mails that had stopped post migration
suddenly started to arrive. The first, which I did not miss (!) was a
notification from Facebook. The second, which I did miss, was all
postings to a non Yahoo mailing list. I don't really know enough about
headers to post them for examination - or more correctly, I'm not sure
which parts I shouldn't post! Anyway, switching off SPF seems to have
had the desired effect, and I will continue to be vigilant when
receiving messages purporting to arrive from Paypal etc.
--
Graeme

[John Hall]

In article <Vm9rdQxh...@nospam.demon.co.uk>,

News <Gra...@nospam.demon.co.uk> writes:
>Anyway, switching off SPF seems to have had the desired effect,

Good.

>and I will continue to be vigilant when receiving messages
>purporting to arrive from Paypal etc.

IIRC, Paypal say that any genuine email from them will have your name
(i.e. the one in your account details) included in the body of the
email. (So it will begin "Hello John Smith" or whatever.) Looking for
that should weed out most of the forgeries.

[Neil Jackson]

On 19/11/2012 20:02, News wrote:
> In message <aEtqs.598679$Ol2.4...@fx25.am4>, Neil Jackson
> <ja...@techno.demon.co.uk.invalid> writes
>
> <snip extremely useful information>
>
>> The solution is *NOT* 'use SPF'.
>>
>> My apologies again for assuming to 'correct' Richard's definition;
>> hopefully he/you won't mind unduly as my intentions are honourable! :)
>
> Neil, thank you. I now feel that I understand the risk involved, if not
> the technicalities behind it.

Glad to have helped, Graeme.

> I asked for SPF to be switched off last
> week, and received a message from Demon, saying that it had been
> switched off today.
>
> Lo and behold, two series of e-mails that had stopped post migration
> suddenly started to arrive. The first, which I did not miss (!) was a
> notification from Facebook. The second, which I did miss, was all
> postings to a non Yahoo mailing list. I don't really know enough about
> headers to post them for examination - or more correctly, I'm not sure
> which parts I shouldn't post! Anyway, switching off SPF seems to have
> had the desired effect, and I will continue to be vigilant when
> receiving messages purporting to arrive from Paypal etc.

At the risk of boring, I'll try and summarise what is and was happening
with the Facebook messages.

Facebook.com's DNS data (on the primary machine that is 'boss' for
Facebook's DNS data - a.ns.facebook.com) reveals a TXT record containing:

"v=spf1 ip4:69.63.179.25 ip4:69.63.178.128/25 ip4:69.63.184.0/25
ip4:66.220.144.128/25 ip4:66.220.155.0/24 ip4:69.171.232.128/25
ip4:66.220.157.0/25 ip4:69.171.244.0/24 mx -all"

In a nutshell, that's a list of all IP addresses which Facebook consider
'valid' as potential senders of emails with 'facebook.com' as the latter
half of their 'SMTP MAIL FROM' envelope header (ie the 'from' header
that mailservers see during the handover process, not the 'from header
that we humans see in our email programs).

Note particularly the '-all' bit at the end - the 'catch all'. That's
Facebook's way of saying "if the IP address giving you facebook.com
email is not on this list, then we denounce it utterly (i.e. 'hardfail')"

Now, this data languishes unseen in Facebook's DNS until someone deigns
to check it. Pre-migration, Demon never checked it. Post-migration, they
have started to (unless you get off it, as you have just done).

When Demon do an SPF validation, they examine the SMTP envelope of the
incoming message to find the bit after the @ (the domain) and then they
look up TXT records in that domain's DNS servers, hunting for a valid
SPF record (i.e. one that starts with v=spf1 or similar).

If they don't find one, that's the end of the quest - this domain
clearly doesn't vouch for its mailservers' IP addresses using SPF, so
nothing good nor bad should be deduced, and the message (hopefully)
proceeds unhindered through that SPF-checking step. It may also now be
marked (by Demon, the receiving-mailserver) internally in the headers as
'SPF=none' or similar, or not marked at all.

However, if Demon DO find a valid SPF record, the next step is to
determine whether the mailserver currently trying to send a message
purporting to be from this domain under scrutiny, has an IP address that
matches one on this newly-found list. If it does match, then the message
is considered validated by the SPF process and again, proceeds
unhindered on to the next mail-checking steps, if there are any, and/or
delivery to the recipient. It may be marked 'SPF=passed' or similar, in
the process.

However, if the mailserver's IP address does *not* match any of the IP
addresses on this SPF list (or any of the expanded lists referred to in
it), then it is deemed to have failed. Demon then need to determine the
severity of this failure, using the opinion of the people who run the
domain. In this case, Facebook have deemed (via the '-all' setting) that
failures are all 'hardfail' - i.e. highest severity. They have opted to
warn everybody that 'Facebook' email from IP addresses other than
theirs, are most-seriously undesirable. Demon responds to this discovery
by simply deleting the message and hanging up the connection from the
incoming mailserver that's trying to send it. Google, in contrast, will
merely mark the message 'SPF=hardfail' and carry on processing it (but
possibly with a dimmer view of it, and presumably a greater possibility
of it ending up in a spam or quarantine bucket which the user may have
to manually check to find it).

And it's that simple. Works great, on the face of it, doesn't it?

Except when - as you have discovered - you have your *genuine* Facebook
mail sent first to 'us...@mydomain.com' and then forwarded on to your
'us...@myhost.demon.co.uk' address.

In this situation, the intermediate ISP (responsible for mail in the
mydomain.com domain) will connect to Demon and duly begin to hand over
the email, but crucially, it will still be using the original SMTP
'from' envelope header (i.e. MAIL FROM: some...@facebook.com) during
the handover conversation. Demon in due course, will repeat the
SPF-checking operation; it'll look for TXT/SPF records in Facebook's
DNS, and then scan any found list for the IP address of the mailserver
which is connected to them at the time (i.e. mydomain.com's mailserver's
IP address). But of course, this time, it will NOT find it on Facebook's
list of nominated servers. So it will fall back to Facebook's 'catch
all' severity and handle the message on that basis - and because Demon's
methodology for '-all' hardfails is 'delete it', your message ends up in
the bin. Plonk!

If Facebook had opted for a lower level of severity (~all : softfail, or
?all : neutral) then Demon would not have deleted the message, and would
have just marked it somewhere and carried on handling it, albeit maybe
with 'kid gloves' now (much like Google do).

Alternatively, if Demon weren't quite so 'trusting' with regards to
their belief that hardfail is *always* a reason for deletion, then
similarly, we might still get messages. Personally, if Demon opted for a
'marking of hardfails' strategy I would have been marginally more
tempted to continue allowing use of SPF-checking of my inbound email
(because it can be a useful extra data-point when measuring for
spamminess). But when a major ISP routinely deletes *all* hardfail
messages, knowing full well that a lot of its users will be using
vanity-domain email-forwarding, this is imho cavalier behaviour, and
(unless they offer alternative handling) the only option to prevent
forwarded email vanishing, is to get SPF-checking turned off. Demon then
stop doing the initial lookup of the connecting mailserver's IP address
in the envelope-sender's DNS, and thus is tantamount to 'doing nothing'
or 'finding no SPF data'.

As Richard says, it will mean that on occasion, you'll get email from
random third-party addresses that have not been 'denounced' by the
genuine domain's DNS/SPF data when they should have been, but if you
(i.e. one, the user generally) don't know to read headers or check the
authenticity of OTHER types of spoofed email, this actually of marginal
benefit, and (imho) will lull one into a false sense of security anyway.

It's also true that if a domain decides to use 'softfail' or 'neutral'
as its public opinion on 'severity of fails', then you will STILL
receive spoofed emails that have that domain's email addresses in the
SMTP envelope headers - so again, most users may misread the level of
security brought by SPF, and falsely trust it.

I have a feeling that SPF is more about protection from liability of the
spoofed domain, than any real attempt to stop users getting junk or
dangerous phishing emails. In other words, the legal beagles wanted
something that enables them to stand up in court and prove to the most
technically-illiterate of judges that they've taken all "necessary
precautions" to prevent spoofed SMTP envelopes. It won't actually stop
*all* spoofed 'from' headers (in-message or in-envelope), or stop
phishing emails crafted by other methods (e.g. such as sending them via
hacked machines inside the spoofed domain's own network, thus using
genuine IP addresses). But it will make life easier for lawyers looking
to blame it on the poor sod who fell for it.

As always, it's not really about our protection, it's about theirs - but
they'll tell us it's about ours, in order to make us all adopt it...

"A million flies can't be wrong. Eat SPF!"

I neglected (until now) to mention one last 'catch all' setting that a
domain can adopt. The SPF standard includes '+all' as a setting which
basically says "also trust everything that *isn't* on the list of IP
addresses given here in our DNS's SPF record". In a sense, it's a
'vouch-all'. I've never been entirely sure why the SPF spec did this -
perhaps for testing, or perhaps they were aware that some domains would
need 'everything everywhere' capability. But the point is, this
technique means that some domains - those who think SPF sucks, but who
realise that some really stupid ISPs or mailservers *may* throw mail
away even if it simply doesn't have an SPF record at all (i.e. the
'SPF=none' case above) - can prevent this, and have that mailserver look
them up and still 'pass' the SPF test.

However, it also opens a door for spammers, and we're already seeing it
happen. The spammer registers a throwaway domain at some low-quality
DNS-registrar/DNS-host in a foreign country, and sets up the throwaway
domain's DNS data to include an "v=spf1 +all" TXT record. He then begins
mass-emailing messages from a billion hijacked PCs 'out there' in his
botnet, and each outgoing message has an SMTP 'MAIL FROM' envelope
address purporting to be from his throwaway domain. Any mailserver en
route that does SPF lookups will check the throwaway domain's DNS data
for an SPF record and will find the simple '+all' entry therein. At that
point, the receiving mailserver will believe this mail to be 'genuine'
(in the context that it has genuinely come from 'throwaway domain'),
will mark it 'SPF=passed' and continue its delivery. So they've proved
and protected nothing at all, just wasted some resources looking things
up in the DNS.

Of course the throwaway domain will eventually reach the spam
blacklists, or be deleted when it turns out the credit-card used to pay
for it was stolen, or the simple fact that the botnetted PCs will all
end up being IP blacklisted will render them useless - but the spammer
won't care. He'll just move on to his next bunch of unhindered zombie
PCs, create a new domain (perhaps with a new registrar or a different
credit-card) and begin the trick. He's getting paid for this, don't forget.

On the face of it, such '+all' tricks aren't *necessarily* going to put
us at greater risk, but there are dangers when you look more closely. As
always, it's the human factors that are most evident here:

If the in-message 'from' header was a Paypal.com address, the end-user
is potentially more prone to believe it. "All my email is SPF-checked,
after all, and if this one got through, it must be ok, surely?" goes the
reasoning.

Secondly, some ISPs (naming no names) appear to be relying more strongly
on SPF validation successes than they do on old-fashioned anti-spam
checks, like looking up IP addresses in realtime blacklists (RBLs such
as SpamCop, Spamhaus, et al). Some may even be *circumventing* those RBL
checks if a message has 'SPF-validated' itself, to save on resources -
in which case such tricks as we've seen with the throwaway domain '+all'
trick can result in the message being more trusted at a machine-level.
This would be madness, of course, but there is the potential for this to
happen. I never ever thought Demon would 'believe' in SPF to the degree
it already has - goodness knows what level of belief other ISPs might
apply to it!

At the very least, the presence of the '+all' trick means that nothing
much has really changed from the old days.

We'll still get spoofed.

Technicians will still *easily* be able to see (after the fact) whether
a message genuinely came from a 'from' header's stated domain. End-users
on the whole will still struggle to work this out reliably.

Judges will still believe what they're told by 'experts', and lawyers
will still rub their hands and fill their wallets, just a bit more
easily than before.

People will still get phished, but the difference now is they'll also
lose more genuine email, especially if they forward it to themselves
from their other accounts, or if a genuine mail-sender misconfigures
their own SPF records (as regularly happens).

Marvellous, isn't it? Solution, it is not.

--
Neil

[Richard Clayton]

In article <aEtqs.598679$Ol2.4...@fx25.am4>, Neil Jackson <jacko@techn
o.demon.co.uk.invalid> writes

>...I'd say SPF is a dead duck.

some attempt is being made to revive this duck with DMARC

essentially SPF tells you one thing about the (lack of) provenance of an
email and to make a good decision you need to know many things, and an
industry has been growing up to carry the policy messages from sender to
receiver as to what should be done in various circumstances. DMARC
attempts to democratise/deskill that industry :)

[Neil Jackson]

On 20/11/2012 12:05, Richard Clayton wrote:
> In article <aEtqs.598679$Ol2.4...@fx25.am4>, Neil Jackson <jacko@techn
> o.demon.co.uk.invalid> writes
>
>> ...I'd say SPF is a dead duck.
>
> some attempt is being made to revive this duck with DMARC

At the risk of inferring too much, I'm reading into your statement that
you believe the SPF duck to be a deceased one too? (I shall refrain from
reciting the Monty Python parrot sketch at this time). :)

>
> essentially SPF tells you one thing about the (lack of) provenance of an
> email and to make a good decision you need to know many things, and an
> industry has been growing up to carry the policy messages from sender to
> receiver as to what should be done in various circumstances. DMARC
> attempts to democratise/deskill that industry :)

Very interesting. I wasn't aware of DMARC. I am in the process of
getting up to speed now. Many thanks for the heads-up.

--
Neil

[ppint. at pplay]

- hi; in article, <_XKqs.299392$nB6.1...@fx21.am4>,
ja...@techno.demon.co.uk.invalid "Neil Jackson" advised:

> Richard Clayton wrote:
>>> ...I'd say SPF is a dead duck.
>> some attempt is being made to revive this duck with DMARC
>
>At the risk of inferring too much, I'm reading into your statement that
>you believe the SPF duck to be a deceased one too? (I shall refrain from
>reciting the Monty Python parrot sketch at this time). :)

- good; elsewise, we might end up discussing the sad case of
the parrot that didn't quack in the night... - did you know
that parrots don't mimic people's voices, other birds, or any-
thing else, in the wild?

>> essentially SPF tells you one thing about the (lack of) provenance of an
>> email and to make a good decision you need to know many things, and an
>> industry has been growing up to carry the policy messages from sender to
>> receiver as to what should be done in various circumstances. DMARC
>> attempts to democratise/deskill that industry :)
>
>Very interesting. I wasn't aware of DMARC. I am in the process of getting

- from the discussion surrounding a demonic incident involving
a certain red button a while back now, if not from stuff on de-
sign theory before that, i've been labouring under the impression
that "spf" stood for "single point [of] failure".

- i'm still not sure it does not.

- love, ppint.
[drop the "v", and change the "f" to a "g", to email or cc.]
--
Vat girls - the missing piece to the puzzle of Utopia.
- "quadibloc" (j savard @ecn.dot.ab.dot.ca) on rasfwr
(09:08:03 -0700) 16:08:03 gmt 14/8/10 (8/14/10 for merkins)

[Simon Turner]

On Tuesday, in article <ZpVls2iT...@highwayman.com>

ric...@highwayman.com "Richard Clayton" wrote:

> In article <aEtqs.598679$Ol2.4...@fx25.am4>, Neil Jackson <jacko@techn
> o.demon.co.uk.invalid> writes
>
> >...I'd say SPF is a dead duck.
>
> some attempt is being made to revive this duck with DMARC
>
> essentially SPF tells you one thing about the (lack of) provenance of an
> email and to make a good decision you need to know many things, and an
> industry has been growing up to carry the policy messages from sender to
> receiver as to what should be done in various circumstances. DMARC
> attempts to democratise/deskill that industry :)

Oh goody. Given that it regards SPF as a Good Thing, despite its many
flaws, DMARC doesn't exactly fill me with joy. I can see it breaking
even more things than SPF currently does, with its idea of "alignment".

And of course those providers who currently force SPF checking on people
("because it's what the sender wants us to do!") will have even more
apparent support for their clueless strong-arm tactics.

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

[Roy Brown]

In message <UiJqs.516605$A%.402263@fx26.am4>, Neil Jackson
<ja...@techno.demon.co.uk.invalid> writing at 10:53:35 in his/her local
time opines:-

<snip>

>When Demon do an SPF validation,

....

> if the mailserver's IP address does *not* match any of the IP
>addresses on this SPF list (or any of the expanded lists referred to in
>it), then it is deemed to have failed. Demon then need to determine the
>severity of this failure, using the opinion of the people who run the
>domain. In this case, Facebook have deemed (via the '-all' setting)
>that failures are all 'hardfail' - i.e. highest severity. They have
>opted to warn everybody that 'Facebook' email from IP addresses other
>than theirs, are most-seriously undesirable. Demon responds to this
>discovery by simply deleting the message and hanging up the connection
>from the incoming mailserver that's trying to send it.

Demon assure me that they make this check during the SMTP conversation,
and bounce the message on a hardfail, not just accept and silently
delete it.

So, for legitimate, 'incorrectly' hardfailed messages, there should at
least be a bounce winging its way back towards the sender.

Whether it gets there or not (and mine didn't) I guess depends on what
the intermediate steps do; my guess is that Gradwell, my relay service,
didn't/couldn't return it to me for some reason.
--
Roy Brown 'Have nothing in your houses that you do not know to be
Kelmscott Ltd useful, or believe to be beautiful' William Morris

[Neil Jackson]

On 23/11/2012 15:01, Roy Brown wrote:
> In message <UiJqs.516605$A%.402263@fx26.am4>, Neil Jackson
> <ja...@techno.demon.co.uk.invalid> writing at 10:53:35 in his/her local
> time opines:-
>
> <snip>
>
>> When Demon do an SPF validation,
> ....
>> if the mailserver's IP address does *not* match any of the IP
>> addresses on this SPF list (or any of the expanded lists referred to
>> in it), then it is deemed to have failed. Demon then need to determine
>> the severity of this failure, using the opinion of the people who run
>> the domain. In this case, Facebook have deemed (via the '-all'
>> setting) that failures are all 'hardfail' - i.e. highest severity.
>> They have opted to warn everybody that 'Facebook' email from IP
>> addresses other than theirs, are most-seriously undesirable. Demon
>> responds to this discovery by simply deleting the message and hanging
>> up the connection from the incoming mailserver that's trying to send it.
>
> Demon assure me that they make this check during the SMTP conversation,
> and bounce the message on a hardfail, not just accept and silently
> delete it.

That's a useful clarification of their position, Roy - thanks for the
update. I'll be honest, though - I have yet to see physical evidence of
such a bounce in this form (and my account is now SPF-off, so I can't
test it any longer). It's probably moot, but Demon have been wrong
before about their 'own' stuff (especially when it's contracted-out).
I'm not saying they're wrong - merely that the jury is still out until
the evidence appears! :)

>
> So, for legitimate, 'incorrectly' hardfailed messages, there should at
> least be a bounce winging its way back towards the sender.
>
> Whether it gets there or not (and mine didn't) I guess depends on what
> the intermediate steps do; my guess is that Gradwell, my relay service,
> didn't/couldn't return it to me for some reason.

Indeed - your lack of bounce from Gradwell is one reason (of several
I've read about) why my jury is still out. Yours is a key test - few
folks (unless they have something like a corporate account which is
SPF-validated in the DNS *and* a vanity account through which they
forward to Demon) are going to have the capability to run such a test.
Few organisations seem to report to their intended end-users (via a
web-page or alternative email address) when mail to their end-user fails
for SPF reasons, so in most cases, it's an undetectable situation. This
is what makes it so much harder to debug.

At least Demon's clarification implies that they've set it up right...
but it would still be good to know they IntY actually *have*!

Thanks again.
--
Neil

[Richard_C]

Back in the day (last June) one of my contacts did get an spf bounce and
called me, so it does bounce rather than silently delete. That's what
got me on the spf alert the day after migration. However if the
forwarded mail comes from an automated server such as an amazon order
confirmation, a bounce is useless.

I quickly redirected my work e-mail to yahoo and pop3 collect from there
- Demon couldn't (wouldn't) offer spf free mail back then.

[Simon Turner]

On Monday, in article <DlHss.351680$YJ1.2...@fx09.am4>

Having just set a domain up with an SPF record enging in -all and had a
play, I can confirm that the Demon servers do, indeed, reject messages
at the SMTP level if the sender address gets an SPF FAIL ("hardfail"):

-> MAIL FROM:<spf@[mydomain]>
<- 550 5.7.1 <spf@[mydomain]>: Sender address rejected: Please see http://www.openspf.org/Why?id=spf%40[mydomain]&ip=[myip]&receiver=mdfmta002.tch.inty.net : Reason: mechanism

After changing the SPF record to end in ~all (softfail), the message was
accepted and delivered normally.

(I note that Richard_C has reported an SPF rejection back in June, but I
wanted to test the current state of play.)

[Simon Turner]

On Monday, in article <ZxJss.777196$Ol2....@fx25.am4>

ric...@nospam.demon.co.uk "Richard_C" wrote:

> Back in the day (last June) one of my contacts did get an spf bounce and
> called me, so it does bounce rather than silently delete. That's what
> got me on the spf alert the day after migration. However if the
> forwarded mail comes from an automated server such as an amazon order
> confirmation, a bounce is useless.

Interestingly, amazon.co.uk's SPF record ends in ~all (softfail), but
amazon.com's ends with -all (hardfail); so only forwarded mail from
amazon.com should have been rejected purely for SPF failure. (Unless
Demon's attitude to softfails has changed since June, which is entirely
possible.)

They are currently happy to accept mail from a forged amazon.co.uk
address:

-> MAIL FROM:<inv...@amazon.com>
<- 550 5.7.1 <inv...@amazon.com>: Sender address rejected: [...]
-> RSET
<- 250 2.0.0 Ok
-> MAIL FROM:<inv...@amazon.co.uk>
<- 250 2.1.0 Ok

[Brian]

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

> On 23/11/2012 15:01, Roy Brown wrote:
>>
>> Demon assure me that they make this check during the SMTP conversation,
>> and bounce the message on a hardfail, not just accept and silently
>> delete it.
>
> That's a useful clarification of their position, Roy - thanks for the
> update. I'll be honest, though - I have yet to see physical evidence of
> such a bounce in this form (and my account is now SPF-off, so I can't
> test it any longer). It's probably moot, but Demon have been wrong
> before about their 'own' stuff (especially when it's contracted-out).
> I'm not saying they're wrong - merely that the jury is still out until
> the evidence appears! :)

The assurance given by Demon to Roy is correct. They do not silently
ignore the attempt to send the mail. I wouldn't describe what Demon do
as a "bounce". Maybe it is in Demon Support terms, but it isn't a bounce
as we know it, Jim. In fact Demon do not even see the complete message
as they abruptly terminate any communication after the first couple of
sentences.

>> So, for legitimate, 'incorrectly' hardfailed messages, there should at
>> least be a bounce winging its way back towards the sender.

Yes, there is a returned message. Telnet to the rescue!

First the helo. Then

mail from: ba...@o2.co.uk

I used this address (which I am entitled to) because O2 participates in
SPF.

Then - a termination of our conversation. (I've broken up the line).

550 5.7.1 <ba...@o2.co.uk>: Sender address rejected: Please see
http://www.openspf.org/Why?id=bandj%40o2.co.uk&ip=80.177.21.xxx
&receiver=mdfmta004.tbr.inty.net : Reason: mechanism

>> Whether it gets there or not (and mine didn't) I guess depends on what
>> the intermediate steps do; my guess is that Gradwell, my relay service,
>> didn't/couldn't return it to me for some reason.

It would be a miracle if Gradwell got anything back to return to you to
tell you about what happened.

> Indeed - your lack of bounce from Gradwell is one reason (of several
> I've read about) why my jury is still out. Yours is a key test - few

mail from: forwardi...@gradwell.com

should ensure Gradwell knows what is going on.

mail from: ba...@o2.co.uk

is guaranteed to keep them in the dark.

> folks (unless they have something like a corporate account which is
> SPF-validated in the DNS *and* a vanity account through which they
> forward to Demon) are going to have the capability to run such a test.
> Few organisations seem to report to their intended end-users (via a
> web-page or alternative email address) when mail to their end-user fails
> for SPF reasons, so in most cases, it's an undetectable situation. This
> is what makes it so much harder to debug.
>
> At least Demon's clarification implies that they've set it up right...
> but it would still be good to know they IntY actually *have*!

My domain is in the DNS with mx5 and mx6 at priority 5. mx1 and mx2 are
at priority 10. This is the way nature intended - it makes SPF just a
bad dream.

I can tell my MTA not to use mx5.demon.co.uk and mx6.demon.co.uk. I can
also instruct my MUA to have ba...@o2.co.uk as the envelope from. The
MTA gets no further than its friend telnet did. Now what does it do?

It has been informed by the Demon MTA about openspf so it does the
decent thing and returns the mail with this information in it. Guess
where to? That's correct! To ba...@o2.co.uk. This is an account I rarely
look at.


--
Brian

[John Hall]

In article <20121126.13...@twoplaces.co.uk>,

Simon Turner <si...@twoplaces.co.uk> writes:
>Interestingly, amazon.co.uk's SPF record ends in ~all (softfail), but
>amazon.com's ends with -all (hardfail); so only forwarded mail from
>amazon.com should have been rejected purely for SPF failure. (Unless
>Demon's attitude to softfails has changed since June, which is entirely
>possible.)

Demon were certainly rejecting forwarded mail from amazon.co.uk as
recently as September, which was when - shortly after my migration - I
managed to get them to turn SPF checking off for my account.

[Simon Turner]

On Monday, in article
<P+7xYCI+...@jhall.demon.co.uk.invalid>

nospam...@jhall.co.uk "John Hall" wrote:

> In article <20121126.13...@twoplaces.co.uk>,
> Simon Turner <si...@twoplaces.co.uk> writes:
> >Interestingly, amazon.co.uk's SPF record ends in ~all (softfail), but
> >amazon.com's ends with -all (hardfail); so only forwarded mail from
> >amazon.com should have been rejected purely for SPF failure. (Unless
> >Demon's attitude to softfails has changed since June, which is entirely
> >possible.)
>
> Demon were certainly rejecting forwarded mail from amazon.co.uk as
> recently as September, which was when - shortly after my migration - I
> managed to get them to turn SPF checking off for my account.

That fits in with the reports that people were getting Amazon
notifications rejected; they can't all have been using amazon.com! I
wonder whether amazon.co.uk changed their SPF to ~all, or Demon changed
their SPF handling to let SPF softfails through? Certainly they don't
reject amazon.co.uk outright now...

[John Hall]

In article <20121126.20...@twoplaces.co.uk>,

Simon Turner <si...@twoplaces.co.uk> writes:
>On Monday, in article
> <P+7xYCI+...@jhall.demon.co.uk.invalid>
> nospam...@jhall.co.uk "John Hall" wrote:
>
>> In article <20121126.13...@twoplaces.co.uk>,
>> Simon Turner <si...@twoplaces.co.uk> writes:
>> >Interestingly, amazon.co.uk's SPF record ends in ~all (softfail), but
>> >amazon.com's ends with -all (hardfail); so only forwarded mail from
>> >amazon.com should have been rejected purely for SPF failure. (Unless
>> >Demon's attitude to softfails has changed since June, which is entirely
>> >possible.)
>>
>> Demon were certainly rejecting forwarded mail from amazon.co.uk as
>> recently as September, which was when - shortly after my migration - I
>> managed to get them to turn SPF checking off for my account.
>
>That fits in with the reports that people were getting Amazon
>notifications rejected; they can't all have been using amazon.com! I
>wonder whether amazon.co.uk changed their SPF to ~all, or Demon changed
>their SPF handling to let SPF softfails through? Certainly they don't
>reject amazon.co.uk outright now...
>

Here are the relevant headers from a message from Amazon UK (forwarded
via Gradwell) that I received via gmail on 31st October. (When I became
aware that SPF might be an issue I set up a gmail account and started
forwarding my email there as well as to Demon.)

From: "auto-c...@amazon.co.uk" <auto-c...@amazon.co.uk>

Date: Wed, 31 Oct 2012 14:59:34 +0000

Received-SPF: fail (google.com: domain of
20121031145934fec93157e...@bounces.amazon.com does
not designate 195.74.61.89 as permitted sender) client-ip=195.74.61.89;

Authentication-Results: mx.google.com; spf=hardfail (google.com: domain
of 20121031145934fec93157e...@bounces.amazon.com
does not designate 195.74.61.89 as permitted sender)
smtp.mail=20121031145934fec93157e...@bounces.amazon.c
om; dkim=pass header.i=auto-c...@amazon.co.uk

Note that although the message is from amazon.co.uk, the specified
originator for SPF purposes is google.com, and a hardfail is generated
(which luckily gmail lets me see but does not act on).

[Simon Turner]

On Monday, in article
<slrnkb7468...@mymachine.invalid> ba...@o2.co.uk

"Brian" wrote:

> On 26-11-2012, Neil Jackson <ja...@techno.demon.co.uk.invalid> wrote:
>
> > On 23/11/2012 15:01, Roy Brown wrote:

> >> Whether it gets there or not (and mine didn't) I guess depends on what
> >> the intermediate steps do; my guess is that Gradwell, my relay service,
> >> didn't/couldn't return it to me for some reason.
>
> It would be a miracle if Gradwell got anything back to return to you to
> tell you about what happened.

I think you may have misunderstood the part Gradwell play in this: AIUI
Roy is sending his mail through their SMTP relay service, and he was
sending mail from one of his other mail addresses to his Demon address.
Gradwell's MTA is the one that gets the SMTP rejection from Demon, and
they should therefore construct and send a DSN ("bounce") back to the
envelope-from address Roy used on his message; but said DSN doesn't seem
to arrive. That is definitely odd, unless something between Gradwell
and Roy's any-mail address is discarding DSNs (which is not
inconceivable).

This lack of DSN is why Neil was speculating that perhaps Demon were
accepting the mail and then dropping it on the floor. We now know that
not to be the case, so something else is going on.

> > Indeed - your lack of bounce from Gradwell is one reason (of several
> > I've read about) why my jury is still out. Yours is a key test - few
>
> mail from: forwardi...@gradwell.com
>
> should ensure Gradwell knows what is going on.
>
> mail from: ba...@o2.co.uk
>
> is guaranteed to keep them in the dark.

If it's a Gradwell MTA that gets the SMTP rejection from Demon, they are
hardly in the dark. The only way they would be in the dark would be if
Demon *was* accepting the mail and then doing something else with it,
which we know is not the case...

> I can tell my MTA not to use mx5.demon.co.uk and mx6.demon.co.uk. I can
> also instruct my MUA to have ba...@o2.co.uk as the envelope from. The
> MTA gets no further than its friend telnet did. Now what does it do?
>
> It has been informed by the Demon MTA about openspf so it does the
> decent thing and returns the mail with this information in it. Guess
> where to? That's correct! To ba...@o2.co.uk. This is an account I rarely
> look at.

But, outside your artificial test, the envelope-from is the real sender,
who presumably looks at their mail less rarely. 8-) (Modulo unmonitored
sending accounts, of course.)

(Roy, if you're interested in finding out whether Gradwell is generating
a DSN, get in touch: you can use Gradwell to relay from an SPF'ed
address of mine to an address at my still-SPF-enabled Demon account, and
I can then see whether a DSN appears or not. I'd test it myself, but I
don't have Gradwell's relay service.)

[Roy Brown]

In message <slrnkb7468...@mymachine.invalid>, Brian
<ba...@o2.co.uk> writing at 15:55:00 in his/her local time opines:-

>> On 23/11/2012 15:01, Roy Brown wrote:

>>> Whether it gets there or not (and mine didn't) I guess depends on what
>>> the intermediate steps do; my guess is that Gradwell, my relay service,
>>> didn't/couldn't return it to me for some reason.

>It would be a miracle if Gradwell got anything back to return to you to
>tell you about what happened.

Ah, I continue to learn.

So you are saying that even though it is Gradwell having the SMTP
conversation with Demon during which the message is refused, it is not
Gradwell to whom the refusal is directed?

I though perhaps that Gradwell got the refusal, but since their
conversation with me was over, they were perhaps sending any refusal
notification to an address in the message that would not reach me. Or
not sending one at all, possibly?

I ought to ask them....

[Simon Turner]

On Monday, in article
<be00gJNA...@jhall.demon.co.uk.invalid>

nospam...@jhall.co.uk "John Hall" wrote:

> Here are the relevant headers from a message from Amazon UK (forwarded
> via Gradwell) that I received via gmail on 31st October. (When I became
> aware that SPF might be an issue I set up a gmail account and started
> forwarding my email there as well as to Demon.)
>
> From: "auto-c...@amazon.co.uk" <auto-c...@amazon.co.uk>
>
> Date: Wed, 31 Oct 2012 14:59:34 +0000
>
> Received-SPF: fail (google.com: domain of
> 20121031145934fec93157e...@bounces.amazon.com does
> not designate 195.74.61.89 as permitted sender) client-ip=195.74.61.89;

Ah, that explains it: although the message is from Amazon UK, the
envelope-from was *@bounces.amazon.com, so it's amazon.com's SPF record
being checked by gmail; hence the -all rather than amazon.co.uk's ~all.

> Authentication-Results: mx.google.com; spf=hardfail (google.com: domain
> of 20121031145934fec93157e...@bounces.amazon.com
> does not designate 195.74.61.89 as permitted sender)
> smtp.mail=20121031145934fec93157e...@bounces.amazon.c
> om; dkim=pass header.i=auto-c...@amazon.co.uk
>
> Note that although the message is from amazon.co.uk, the specified
> originator for SPF purposes is google.com,

google.com is the reporter, not the originator: mx.google.com is the one
performing the SPF checks. The mail arrives from 195.74.61.89, aka
gwh-4.gradwell.net, and the amazon.com SPF record disowns that IP
address.

[Neil Jackson]

On 27/11/2012 10:37, Simon Turner wrote:
> On Monday, in article
> <slrnkb7468...@mymachine.invalid> ba...@o2.co.uk
> "Brian" wrote:
>
>> On 26-11-2012, Neil Jackson <ja...@techno.demon.co.uk.invalid> wrote:
>>
>>> On 23/11/2012 15:01, Roy Brown wrote:
>
>>>> Whether it gets there or not (and mine didn't) I guess depends on what
>>>> the intermediate steps do; my guess is that Gradwell, my relay service,
>>>> didn't/couldn't return it to me for some reason.
>>
>> It would be a miracle if Gradwell got anything back to return to you to
>> tell you about what happened.
>
> I think you may have misunderstood the part Gradwell play in this: AIUI
> Roy is sending his mail through their SMTP relay service, and he was
> sending mail from one of his other mail addresses to his Demon address.
> Gradwell's MTA is the one that gets the SMTP rejection from Demon, and
> they should therefore construct and send a DSN ("bounce") back to the
> envelope-from address Roy used on his message; but said DSN doesn't seem
> to arrive. That is definitely odd, unless something between Gradwell
> and Roy's any-mail address is discarding DSNs (which is not
> inconceivable).
>
> This lack of DSN is why Neil was speculating that perhaps Demon were
> accepting the mail and then dropping it on the floor. We now know that
> not to be the case, so something else is going on.

Exactly, Simon - well summarised, and thanks for saving me the trouble
(again!) :)

My thanks also to Richard_C, Brian and John Hall for providing evidence
that Demon is indeed rejecting the 'MAIL FROM' envelope at
SMTP-transaction time - which of course puts the onus on the SENDING
mailserver to generate a 'bounce' message back to the sender*.

I am now satisfied that Demon *are* doing SMTP-rejection when faced with
SPF-hardfailing senders. As Brian rightly pointed out, this is *not*
'sending a bounce' as the Demon frontline-tech-scriptreaders refer to it
- which is precisely why I had not accepted their unclear answer as
'fact' until proven. Thanks to you lot, I am now happy that their
hardnosed implementation of SPF is at least being done 'properly' (in
terms of generating an SMTP rejection at the point of transfer, rather
than
'silently-accepting-then-deleting-and-possibly-doing-a-bounce-message'
which would've been plain mad). I still don't agree with the policy in
terms of its level of rejection, but it's implementation in terms of its
method of rejection is at least 'normal').

Thanks to you all for the detective work and record-keeping! :)

>
>>> Indeed - your lack of bounce from Gradwell is one reason (of several
>>> I've read about) why my jury is still out. Yours is a key test - few
>>
>> mail from: forwardi...@gradwell.com
>>
>> should ensure Gradwell knows what is going on.
>>
>> mail from: ba...@o2.co.uk
>>
>> is guaranteed to keep them in the dark.
>
> If it's a Gradwell MTA that gets the SMTP rejection from Demon, they are
> hardly in the dark. The only way they would be in the dark would be if
> Demon *was* accepting the mail and then doing something else with it,
> which we know is not the case...

Brian does have a point about Gradwell potentially 'being in the dark' -
at least I'd say that Roy's sending arrangement could be a 'grey area'
in terms of backscatter rules...

I am beginning to wonder whether the problem arises from the fact that
the original envelope-from stems from a domain that is not under direct
Gradwell control. It was sent 'From' (and presumably 'MAIL FROM'
enveloped-from) Roy's SPFed 'vanity domain' k****.co.uk, DNS-hosted
elsewhere (the place that had the 'hidden' SPF record with the hardfail
catch-all).

It may also be relevant that Roy's physical network connection was not a
Gradwell-origin IP address (he was connected to Gradwell's SMTP relay
from a Sky Broadband IP address (and even though his Turnpike was
identifying itself to Gradwell at the HELO using his *DEMON*
hostname.demon.co.uk name, this should have been counteracted by the
fact that he was using SMTP-Authentication on the Gradwell relay). But
still - the Gradwell MTA would have seen that Roy's MUA was 'foreign',
IP-address-wise, and domain-name wise.

I'm wondering if Gradwell simply didn't feel confident enough (by some
metric, possibly all of the above) to be sure that the SMTP
envelope-from was legitimate enough to warrant a DSN? It's possible,
given it was apparently 'off-net' and 'foreign domained', that it fell
foul of Gradwell's backscatter-prevention rules? I could quite believe
that, tbh.

The test would be to see whether it did the same when connecting via (a)
a Gradwell IP and/or (b) with a Gradwell-hosted domain in the
envelope-from. Of course, this is unlikely to be possible now that Roy
has SPF-checking turned off, but maybe John's earlier notification from
Gradwell is a sign that generally they *do* raise a DSN if they're
confident about the sender's location being proximal to them.

--
Neil

[Neil Jackson]

On 27/11/2012 10:44, Roy Brown wrote:
> In message <slrnkb7468...@mymachine.invalid>, Brian
> <ba...@o2.co.uk> writing at 15:55:00 in his/her local time opines:-
>
>>> On 23/11/2012 15:01, Roy Brown wrote:
>
>>>> Whether it gets there or not (and mine didn't) I guess depends on what
>>>> the intermediate steps do; my guess is that Gradwell, my relay service,
>>>> didn't/couldn't return it to me for some reason.
>
>> It would be a miracle if Gradwell got anything back to return to you to
>> tell you about what happened.
>
> Ah, I continue to learn.
>
> So you are saying that even though it is Gradwell having the SMTP
> conversation with Demon during which the message is refused, it is not
> Gradwell to whom the refusal is directed?

Maybe look at it this way...

Gradwell, acting as your 'telegram agent' got hung up on, mid-call by
Demon, with a message telling them (Gradwell) to go away, because Demon
didn't trust Gradwell to be an agent for k***.co.uk telegrams (by virtue
of checking asking k***.co.uk who their agents were - i.e. SPF).

Gradwell are then responsible for letting you (the person whom they are
agent for) know about this inability to deliver. If you had been
originally calling Gradwell from a Gradwell-network internal phone in a
Gradwell telegram office (ie. using a Gradwell IP address), they may
have regarded your given sender-name as genuine, and send you a 'we
failed' telegram back to it, along with the error message from Demon.

However, because you weren't calling from Gradwell's internal network,
AND possibly because you weren't using Gradwell sender-address (you were
using a k****.co.uk one), they can't be sure you're not a spoof yourself
- so may have just decided not to send you any notification of Demon's
rejection at all. Playing safe, to avoid backscatter.

The problem of backscatter is now rife on the internet, to the extent
that (good) mailservers are generally quite careful about whom they send
failure-notifications.

At the risk of teaching granny to suck eggs, here's why:

Imagine that I forge a billion SPAM messages with a 'from' (and
envelope-from') Roy@roysdomain and inject them into an open relay or
(using a hijacked PC) even a closed, customer-only relay such as
Gradwell's, or even Demon's main SMTP smarthost. Assuming that the
mailserver doesn't detect the massive bulk of the email effort or its
spammy content and stop it dead in its tracks, it will begin sending -
and a large proportion (possibly a massive one) will be destined to be
sent to non-existent addresses (because Spammers lists are always out of
date and they don't care about address data-cleansing). This means that
maybe several hundred thousand times, Demon (or Gradwell, or whoever's
doing the mailserver-sending work) will get a 'hang-up' - an SMTP
transaction rejection, akin to the kind we saw in your case. Most
rejections are usually simply because of a non-existent recipient
mailbox - but now, as we have seen, SPF-rejection will cause a large
number too (but only if 'roysdomain' uses SPF-records in its DNS, and
with a hardfail catch-all).

Now, if the enslaved mailserver began sending DSN reports for each of
these rejections, who would it send them to? Obviously, Roy@roysdomain -
because that's who was identified as the envelope-From sender... except
that he didn't send any of them, and was 'joe-jobbed' or spoofed.

Roy@roysdomain now has to cope with the mass-deletion of several hundred
thousand DSNs that are not of his making, none of his business and a
royal pain in the behind. This is backscatter. Nowadays, it's considered
as much of a nuisance as spam, and there are even blacklists of
mailservers that still persist in this 'well-intentioned' but ultimately
cavalier DSN-generation. DSNs now have to be quite tightly controlled -
and usually, the tests of 'is it a local user?' (i.e. is it a
domain-name in the 'From' that we recognise as one of ours?), and/or 'is
it one of our IP addresses?' will suffice. Sometimes STMP-authentication
is a consideration too. It varies. As always, though, tightening the
filters in this way means that sometimes, valid DSNs don't get through.

>
> I though perhaps that Gradwell got the refusal,

They did, yes. Gradwell's outbound SMTP server got told by Demon to run
away and play, followed by a hang-up of the TCP connection on port 25.
"Go-away...Click...Brrrr", leaving Gradwell out in the cold, and
wondering whether to tell you about it.

> but since their
> conversation with me was over, they were perhaps sending any refusal
> notification to an address in the message that would not reach me.

There is of course the possibility that the server which receives email
destined for your k****.co.uk email address, might have rejected the DSN
on principle (most DSNs are sent with a MAIL FROM of '<>' - i.e. blank).
We've not considered this yet. It's quite possible that Gradwell DID
send it, but it got filtered or spiked by whichever ISP it was that
initially picked up the message from Gradwell!

Given that they misconfigured their SPF DNS records for you in such a
way that they didn't turn up when doing a 'dig', but did turn up if
queried individually and directly, anything's possible. They may just
have a 'do not accept mail with a blank envelope-from' policy, for all
we know. This *might* be worth testing...

> Or
> not sending one at all, possibly?

Possibly - and if so, Backscatter Protection would be my best guess.

>
> I ought to ask them....

Do let us know what they come back with. From an academic point of view
only, I'd quite like to know! :)

Cheers
--
Neil

[Neil Jackson]

Beat me to it, Simon! Though I must confess on first reading*, I had
missed the 'amazon.com' envelope-from - though I was sure that I had
encountered the fact that *all* of Amazon's automated notifications came
from their .com addresses. I don't think I've ever seen anything that's
genuinely 'from' (envelope-wise) an amazon.co.uk address - they seem
only to use that domain as an inbound route, and for DK signatures
(which just goes to further show how complicated these two technologies
can get, when configured independently on opposite sides of the
Atlantic, for one corporate entity! The world frankly doesn't stand a
chance of setting it all up 100% right, ever, does it? :))

--
Neil

[Roy Brown]

In message <0K1ts.368823$Wc4....@fx10.am4>, Neil Jackson
<ja...@techno.demon.co.uk.invalid> writing at 11:46:04 in his/her local

time opines:-
>On 27/11/2012 10:44, Roy Brown wrote:
>> In message <slrnkb7468...@mymachine.invalid>, Brian
>> <ba...@o2.co.uk> writing at 15:55:00 in his/her local time opines:-
>>
>>>> On 23/11/2012 15:01, Roy Brown wrote:
>>
>>>>> Whether it gets there or not (and mine didn't) I guess depends on what
>>>>> the intermediate steps do; my guess is that Gradwell, my relay service,
>>>>> didn't/couldn't return it to me for some reason.
>>
>>> It would be a miracle if Gradwell got anything back to return to you to
>>> tell you about what happened.

>> Ah, I continue to learn.

But, as in the famous film:-

Captain Renault: What in heaven's name brought you to Casablanca?
Rick: My health. I came to Casablanca for the waters.
Captain Renault: The waters? What waters? We're in the desert.
Rick: I was misinformed.

>> So you are saying that even though it is Gradwell having the SMTP
>> conversation with Demon during which the message is refused, it is not
>> Gradwell to whom the refusal is directed?

We now know it *is* Gradwell who get it back.

>Maybe look at it this way...

<snip>

>However, because you weren't calling from Gradwell's internal network,
>AND possibly because you weren't using Gradwell sender-address (you
>were using a k****.co.uk one), they can't be sure you're not a spoof
>yourself - so may have just decided not to send you any notification of
>Demon's rejection at all. Playing safe, to avoid backscatter.

I used authentication with Gradwell. They might not be able to be sure
it wasn't a spoof, but I think prudence dictates they should assume it
isn't.

After all, my bank honours my debit card, as long as I give my correct
PIN, even if they send me a text message almost at once to ask 'Are you
*really* in Bora Bora?'

>The problem of backscatter is now rife on the internet, to the extent
>that (good) mailservers are generally quite careful about whom they
>send failure-notifications.
>
>At the risk of teaching granny to suck eggs, here's why:
>
>Imagine that I forge a billion SPAM messages with a 'from' (and
>envelope-from') Roy@roysdomain and inject them into an open relay or
>(using a hijacked PC) even a closed, customer-only relay such as
>Gradwell's,

My modest account with Gradwell allows 100 emails a day. Seeing that, I
think they would not worry about swamping me with backscatter, even if
my AUTH password had been stolen and misused.

<snip good stuff>

>> I though perhaps that Gradwell got the refusal,

>They did, yes. Gradwell's outbound SMTP server got told by Demon to run
>away and play, followed by a hang-up of the TCP connection on port 25.
>"Go-away...Click...Brrrr", leaving Gradwell out in the cold, and
>wondering whether to tell you about it.

Just so. Thanks for the clarification.

>There is of course the possibility that the server which receives email
>destined for your k****.co.uk email address, might have rejected the
>DSN on principle (most DSNs are sent with a MAIL FROM of '<>' - i.e.
>blank). We've not considered this yet. It's quite possible that
>Gradwell DID send it, but it got filtered or spiked by whichever ISP it
>was that initially picked up the message from Gradwell!

>Given that they misconfigured their SPF DNS records for you in such a
>way that they didn't turn up when doing a 'dig', but did turn up if
>queried individually and directly, anything's possible. They may just
>have a 'do not accept mail with a blank envelope-from' policy, for all
>we know. This *might* be worth testing...

This is a chain of reasoning I have been following myself....

>> Or not sending one at all, possibly?

>Possibly - and if so, Backscatter Protection would be my best guess.

>> I ought to ask them....

>Do let us know what they come back with. From an academic point of view
>only, I'd quite like to know! :)

I will. I no longer have the SPF checking on, so I can't provoke a live
example for Gradwell at will, but they ought at least to be able to tell
me what they think they do....

[John Hall]

In article <xi1ts.794556$Rc7.3...@fx04.am4>,

Neil Jackson <ja...@techno.demon.co.uk.invalid> writes:
>I'm wondering if Gradwell simply didn't feel confident enough (by
>some metric, possibly all of the above) to be sure that the SMTP
>envelope-from was legitimate enough to warrant a DSN? It's
>possible, given it was apparently 'off-net' and 'foreign domained',
>that it fell foul of Gradwell's backscatter-prevention rules? I could
>quite believe that, tbh.
>
>The test would be to see whether it did the same when connecting
>via (a) a Gradwell IP and/or (b) with a Gradwell-hosted domain in
>the envelope-from. Of course, this is unlikely to be possible now
>that Roy has SPF-checking turned off, but maybe John's earlier
>notification from Gradwell is a sign that generally they *do* raise a
>DSN if they're confident about the sender's location being
>proximal to them.

?

In the week or so between Demon migrating me and my managing to get SPF
rejection turned off, I never received any notifications from Gradwell
of messages being rejected by Demon (unless Demon rejected the
notification messages as well!), though I know (from my parallel
forwarding of my incoming email to gmail) that Demon did reject a few. I
have my domain hosted by Gradwell and I use their email forwarding
service.

[Brian]

On 27-11-2012, Simon Turner <si...@twoplaces.co.uk> wrote:

> On Monday, in article
> <slrnkb7468...@mymachine.invalid> ba...@o2.co.uk
> "Brian" wrote:
>
>>
>> mail from: forwardi...@gradwell.com
>>
>> should ensure Gradwell knows what is going on.
>>
>> mail from: ba...@o2.co.uk
>>
>> is guaranteed to keep them in the dark.
>
> If it's a Gradwell MTA that gets the SMTP rejection from Demon, they are
> hardly in the dark. The only way they would be in the dark would be if
> Demon *was* accepting the mail and then doing something else with it,
> which we know is not the case...

I expressed myself badly in this section but rather thought I had made
up for it later on.

>> I can tell my MTA not to use mx5.demon.co.uk and mx6.demon.co.uk. I can
>> also instruct my MUA to have ba...@o2.co.uk as the envelope from. The
>> MTA gets no further than its friend telnet did. Now what does it do?
>>
>> It has been informed by the Demon MTA about openspf so it does the
>> decent thing and returns the mail with this information in it. Guess
>> where to? That's correct! To ba...@o2.co.uk. This is an account I rarely
>> look at.
>
> But, outside your artificial test, the envelope-from is the real sender,
> who presumably looks at their mail less rarely. 8-) (Modulo unmonitored
> sending accounts, of course.)

I was concerned to point that it was possible to have incoming mail to a
Demon account subjected to SPF even though SPF was turned off for the
account itself. I thought the technique was quite neat, myself. And it
also confirmed the sending MTA sent a message to the envelope from.


--
Brian

[Brian]

On 27-11-2012, Roy Brown <Roy_now_fre...@acanthus.demon.co.uk> wrote:

> In message <slrnkb7468...@mymachine.invalid>, Brian
><ba...@o2.co.uk> writing at 15:55:00 in his/her local time opines:-
>
>>> On 23/11/2012 15:01, Roy Brown wrote:
>
>>>> Whether it gets there or not (and mine didn't) I guess depends on what
>>>> the intermediate steps do; my guess is that Gradwell, my relay service,
>>>> didn't/couldn't return it to me for some reason.
>
>>It would be a miracle if Gradwell got anything back to return to you to
>>tell you about what happened.
>
> Ah, I continue to learn.
>
> So you are saying that even though it is Gradwell having the SMTP
> conversation with Demon during which the message is refused, it is not
> Gradwell to whom the refusal is directed?

The quality of my expression was poor. Apologies.

Gradwell know the conversation was terminated and is given a reason.
It should direct a message containing the reason to whatever address
was used in the MAIL FROM: line which it used in the conversation.

--
Brian

[Simon Turner]

On Tuesday, in article
<MMv44ADR...@jhall.demon.co.uk.invalid>

Roy is using Gradwell's SMTP relay service, not mail forwarding. The
mail that was rejected was sent by him (via Gradwell) from a separate
address of his that has an SPF record; when Demon rejected the message,
he *should* have received a DSN from Gradwell at that address, but
didn't. Neil is speculating that Gradwell may not have sent the DSN at
all, to avoid backscatter (I'm not sure I agree, because Roy seems to be
using the relay account in the expected manner, but we won't know
without further evidence).

That's a different situation from yours, where Gradwell is forwarding
mail sent to your Gradwell-hosted domain by unknown external senders; in
that case, Gradwell should send DSNs to those unknown senders, not to
you as the domain owner.

(Of course, there's nothing to stop Gradwell noticing that a lot of your
forwarded mail is being rejected, and contacting you -- their customer
-- to tell you about it; but I don't know of any domain mail forwarder
that does such a thing. Might be a useful feature if they did!)

[Simon Turner]

On Tuesday, in article <81yZAuEYkMtQFwXt@x.x>
Roy_now_fre...@acanthus.demon.co.uk "Roy Brown"

wrote:

> In message <0K1ts.368823$Wc4....@fx10.am4>, Neil Jackson
> <ja...@techno.demon.co.uk.invalid> writing at 11:46:04 in his/her local
> time opines:-
> >On 27/11/2012 10:44, Roy Brown wrote:

> >However, because you weren't calling from Gradwell's internal network,
> >AND possibly because you weren't using Gradwell sender-address (you
> >were using a k****.co.uk one), they can't be sure you're not a spoof
> >yourself - so may have just decided not to send you any notification of
> >Demon's rejection at all. Playing safe, to avoid backscatter.
>
> I used authentication with Gradwell. They might not be able to be sure
> it wasn't a spoof, but I think prudence dictates they should assume it
> isn't.
>
> After all, my bank honours my debit card, as long as I give my correct
> PIN, even if they send me a text message almost at once to ask 'Are you
> *really* in Bora Bora?'

It seems to me that you're using Gradwell's relay service (presumably
"SMTP Outbound 100") in its intended manner: they expect you to connect
to it (using authentication) from anywhere on the planet, because that's
what it's for (never having to change your mail settings when you're on
the move).

Do you also have a domain with Gradwell, or do you just buy their relay
service? I note that the description talks about sending "emails from
your domain on the move", which suggests that they *might* look askance
at mail from a different domain; but presumably only if you have a
domain with them.

> >There is of course the possibility that the server which receives email
> >destined for your k****.co.uk email address, might have rejected the
> >DSN on principle (most DSNs are sent with a MAIL FROM of '<>' - i.e.
> >blank). We've not considered this yet. It's quite possible that
> >Gradwell DID send it, but it got filtered or spiked by whichever ISP it
> >was that initially picked up the message from Gradwell!
>
> >Given that they misconfigured their SPF DNS records for you in such a
> >way that they didn't turn up when doing a 'dig', but did turn up if
> >queried individually and directly, anything's possible. They may just
> >have a 'do not accept mail with a blank envelope-from' policy, for all
> >we know. This *might* be worth testing...
>
> This is a chain of reasoning I have been following myself....

I reckon this is the likeliest explanation for the DSN's non-arrival.
I'd be happy to try sending a DSN directly to your any-mail address if
you want; drop me a line telling me what address you want it sent to.

> >> I ought to ask them....
>
> >Do let us know what they come back with. From an academic point of view
> >only, I'd quite like to know! :)
>
> I will. I no longer have the SPF checking on, so I can't provoke a live
> example for Gradwell at will, but they ought at least to be able to tell
> me what they think they do....

My ashes.dcu domain still has SPF checking on; feel free to use it to
provoke an SPF failure if you wish.

[John Hall]

In article <20121127.17...@twoplaces.co.uk>,

That's what I thought, and was why Neil saying "maybe John's earlier

notification from Gradwell is a sign that generally they *do* raise a
DSN if they're confident about the sender's location being proximal to

them" confused me.

>
>(Of course, there's nothing to stop Gradwell noticing that a lot of your
>forwarded mail is being rejected, and contacting you -- their customer
>-- to tell you about it; but I don't know of any domain mail forwarder
>that does such a thing. Might be a useful feature if they did!)
>

Indeed. :)

[Roy Brown]

In message <20121127.17...@twoplaces.co.uk>, Simon Turner
<si...@twoplaces.co.uk> writing at 17:58:02 in his/her local time
opines:-

>On Tuesday, in article <81yZAuEYkMtQFwXt@x.x>
> Roy_now_fre...@acanthus.demon.co.uk "Roy Brown"
> wrote:

>> I used authentication with Gradwell. They might not be able to be sure
>> it wasn't a spoof, but I think prudence dictates they should assume it
>> isn't.
>> After all, my bank honours my debit card, as long as I give my correct
>> PIN, even if they send me a text message almost at once to ask 'Are you
>> *really* in Bora Bora?'

>It seems to me that you're using Gradwell's relay service (presumably
>"SMTP Outbound 100") in its intended manner: they expect you to connect
>to it (using authentication) from anywhere on the planet, because that's
>what it's for (never having to change your mail settings when you're on
>the move).

Exactly. I'm on a client site now, using their wifi, never have to
wonder what their outgoing SMTP is, just use Gradwell.

NIN is doing the same unobtrusive job for this Usenet posting.

>Do you also have a domain with Gradwell, or do you just buy their relay
>service? I note that the description talks about sending "emails from
>your domain on the move", which suggests that they *might* look askance
>at mail from a different domain; but presumably only if you have a
>domain with them.

No, I don't have a domain there. I once found myself using my Turnpike
in an Internet cafe in Spain where the owner declined to tell me the
outgoing SMTP address (it's all AUTH over there, even for your own ISP,
so he wasn't going to tell me a password!), and I declined to use the
webmail services that were keeping everyone else there happy.

I had Gradwell outgoing SMTP inside 30 minutes without ever talking to a
human - very slick.

<snip conjecture about Anymail cocking up>.

>I reckon this is the likeliest explanation for the DSN's non-arrival.
>I'd be happy to try sending a DSN directly to your any-mail address if
>you want; drop me a line telling me what address you want it sent to.

Thanks, I'll do that separately.

>My ashes.dcu domain still has SPF checking on; feel free to use it to
>provoke an SPF failure if you wish.

Good thought. Thank you.

[Jim Crowther]

In demon.service, on Tue, 27 Nov 2012 18:30:25, Roy Brown wrote:

>I'm on a client site now, using their wifi, never have to wonder what
>their outgoing SMTP is, just use Gradwell.
>
>NIN is doing the same unobtrusive job for this Usenet posting.

Likewise - this Acer Aspire notebook has had zero problems sending or
receiving email/news for over three years all over the world using the
combination of Gradwell and NIN with no configuration changes. I've
kept other possibilities up my sleeve 'in case', but have never needed
to use them - so far. ;)

--
Jim Crowther

[Brian]

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

> 'silently-accepting-then-deleting-and-possibly-doing-a-bounce-message'
> which would've been plain mad). I still don't agree with the policy in
> terms of its level of rejection, but it's implementation in terms of its
> method of rejection is at least 'normal').

It makes you wonder, doesn't it? I can understand Demon offering SPF
checking as a service but why was the decision made that

(a) It should be compulsory,
(b) Hardfails should not be allowed to be delivered?

SPF (and mailfilter lite) became selling points, And the best way of
selling someting is to frighten people. It pulls them into line and
stiffles the opposition.

We read at

http://help.demon.net/help-articles/troubleshooting-and-faqs/spf-basic-support/

E-mail is an important part of everyday life, helping businesses of
all kinds to communicate better, make sales and improve productivity.

Unfortunately, spammers and online criminals exploit this type of
communication, threatening email security and personal identity. Left
unchecked, this undermines the trust and confidence of email users,
and makes it increasingly difficult to ensure that legitimate e-mail
is delivered.

Who could argue with that? It has lots of good trigger words in it. If
you didn't catch all of them I'm sure Demon Support will slip them into
whatever discussion you are engaged in with them.

And again:

One specific spam filtering mechanism being used is Sender Policy
Framework. This is an industry standard being implemented by a
number of ISPs and mail hosts to counter the threat of spam from
forged email addresses.

"Industry Standard". That's got to be good. "Spam" - nasty. "Forged" has
to be bad.

But some people do think for themselves. They complain. So Demon altered
(a) above. By my reckoning it took at least six months for it to alter
the situation. It took so long because they had initially determined
what was good for you, so why change. Commercial pressure rather than
principle may have influenced them, I imagine?

The official website answer to

Can I opt out of Sender Policy Framework?

is still "no".

On a technical note: Why does non-SPF mail handling have two backup mx
machines?

--
Brian

[Neil Jackson]

Sorry John - re-reading your original post, I see now that the report
you posted was from Gmail, not Gradwell. Rushing on my part, sorry!

--
Neil

[Neil Jackson]

On 27/11/2012 22:44, Brian wrote:
> On 27-11-2012, Neil Jackson <ja...@techno.demon.co.uk.invalid> wrote:
>
>> 'silently-accepting-then-deleting-and-possibly-doing-a-bounce-message'
>> which would've been plain mad). I still don't agree with the policy in
>> terms of its level of rejection, but it's implementation in terms of its
>> method of rejection is at least 'normal').
>
> It makes you wonder, doesn't it? I can understand Demon offering SPF
> checking as a service but why was the decision made that
>
> (a) It should be compulsory,
> (b) Hardfails should not be allowed to be delivered?

It certainly could not be because everybody who had the slightest clue
about how email works was no longer working at Demon since the takeover,
and it definitely wasn't because the external company that the rump of
remaining Thus middle-managers decided to outsource email to, happened
to believe in this crap because it says so on M$'s sales-blurb for
Exchange. Definitely not, I'm sure.

>
> SPF (and mailfilter lite) became selling points, And the best way of
> selling someting is to frighten people. It pulls them into line and
> stiffles the opposition.
>
> We read at
>
> http://help.demon.net/help-articles/troubleshooting-and-faqs/spf-basic-support/
>
> E-mail is an important part of everyday life, helping businesses of
> all kinds to communicate better, make sales and improve productivity.
>
> Unfortunately, spammers and online criminals exploit this type of
> communication, threatening email security and personal identity. Left
> unchecked, this undermines the trust and confidence of email users,
> and makes it increasingly difficult to ensure that legitimate e-mail
> is delivered.
>
> Who could argue with that? It has lots of good trigger words in it. If
> you didn't catch all of them I'm sure Demon Support will slip them into
> whatever discussion you are engaged in with them.

Especially if it's on their script. Reminds me of the 'Good morning
Window' in the episode of the Young Ones with Helen Lederer as the
robotic bank-teller who could repeat that phrase, and that phrase only.

>
> And again:
>
> One specific spam filtering mechanism being used is Sender Policy
> Framework. This is an industry standard being implemented by a
> number of ISPs and mail hosts to counter the threat of spam from
> forged email addresses.
>
> "Industry Standard". That's got to be good. "Spam" - nasty. "Forged" has
> to be bad.

As I said a while back... "A million flies can't be wrong... eat s***!"

To be totally fair to them, they didn't say which 'Industry' it was a
standard of, did they? For all we know, it might be a legal tenet of the
Thai sex industry, or a bastion of interstate agreement amongst
Lithuanian fish industry workers. Last time I looked, though, it does
seem to be spreading like the creeping death even amongst semi-literate
ISPs - almost as if nobody dare point out the Emperor's butt-cheeks
flapping in the breeze (or, more likely, it's a cost-benefit thing - The
ability to bluff customers that missing mail is their or their
forwarding-ISP's fault, is easier than the technical overhead and
liability issues involved in dealing with customers on the wrong side of
spam/phish/419-scam junk and falling foul of it. Collateral damage is
always easier to sell if you can show people a much larger pile of enemy
bodies than friendly ones - especially if the friendly ones have just
vapourised...)

>
> But some people do think for themselves. They complain. So Demon altered
> (a) above. By my reckoning it took at least six months for it to alter
> the situation. It took so long because they had initially determined
> what was good for you, so why change. Commercial pressure rather than
> principle may have influenced them, I imagine?

They did seem to weaken rather quickly when I exposed some major config
issues with the way they were implementing SPF on the THUS corp DNS
across their own motley collection of servers too though! I think once
they realised that even they could cock-up an SPF installation and cause
several domain-authoritative DNS-servers to all lie in different ways,
they realised they might not be alone, and that SPF was not god, in the
hands of a muppet-sysadmin. Perhaps they saw the first inkling of the
Emperor's nakedness, and decided they couldn't absolutely force everyone
to put up with it too? Just those that hadn't realised they were looking
at a faceful of c**k.

>
> The official website answer to
>
> Can I opt out of Sender Policy Framework?
>
> is still "no".

Standard council-type bureacracy. As you'd expect, they're not going to
signpost something that makes it obvious they've been tw*ts. They'll
hide it "on display in the bottom of a locked filing cabinet stuck in a
disused lavatory with a sign on the door saying 'Beware of the
Leopard'", in true HHGTTG fashion.

>
> On a technical note: Why does non-SPF mail handling have two backup mx
> machines?

Probably because they never thought to delete the two entries that were
previously in the DNS as pref-10 items (mx1 and mx2) - they've simply
added two new ones at pref-5 (mx5 and mx6). Unintentionally, they've
provided a backup, but imho, it's more likely a labour/cost-saving
intent, or just plain oversight. I have a feeling that mx5 and mx6 will
probably point to mailservers 'inside the circled wagons' - i.e. ones
that would normally still be reached, but only after the SPF-checkers
had handled the message first. So if mx5 and mx6 are dead, there's a
fairly good chance that mx1 and mx2 aren't going to be much help,
because whilst they may accept the mail, if they can't pass it on to mx5
or mx6, they'll probably just kill it or circle it until it times out
(and bounce it, possibly, in a blue moon, if it was generated by a
d.c.u. sender).

I certainly don't believe there's a valid technical reason - unless you
count being scared of cutting off a branch they're not sure if they
might be sitting on and might still need, one day. :)

--
Neil

[Neil Jackson]

On 27/11/2012 14:07, Roy Brown wrote:
> In message <0K1ts.368823$Wc4....@fx10.am4>, Neil Jackson
> <ja...@techno.demon.co.uk.invalid> writing at 11:46:04 in his/her local
> time opines:-
>

> <snip>
>
>> However, because you weren't calling from Gradwell's internal network,
>> AND possibly because you weren't using Gradwell sender-address (you
>> were using a k****.co.uk one), they can't be sure you're not a spoof
>> yourself - so may have just decided not to send you any notification
>> of Demon's rejection at all. Playing safe, to avoid backscatter.
>
> I used authentication with Gradwell. They might not be able to be sure
> it wasn't a spoof, but I think prudence dictates they should assume it
> isn't.

It's easy to think that SMTP-auth is a pretty strong determinant that a
user's From address is likely to be good and safe - but it can come down
to the order of precedence of other trust-factors that Gradwell might
have decided upon. If, for example, they believe that 'being on their
local net and having one of their IP addresses' is king, then that may
be the only factor involved. IMHO, most likely it's the fact that the
sender-domain you used was non-local to Gradwell, so (even though they
had your SMTP-auth details) they couldn't guarantee that any DSN would
go to a local mailbox user. And that means it's a backscatter-risk.

>
> After all, my bank honours my debit card, as long as I give my correct
> PIN, even if they send me a text message almost at once to ask 'Are you
> *really* in Bora Bora?'

Not quite a valid comparison, but I can see why you would imagine it
might be.

In truth, the fact that you've SMTP-authed yourself (or rather, your
MUA) proves nothing about the validity of your mail-from envelope
address. In fact, it could be said that it *increases* the possibility
of it being faked, and thus impossible to send anything back to.

In essence, SMTP-auth can be likened to saying to the Gradwell server:
"look, it's me, Roy? See? You don't know my email address, but you trust
my username and password, yes? Great... now, send this message from me,
but don't ask why I've said my name is Santa Claus on the envelope, ok?
It's for the kids...<wink, wink>."

Given that Gradwell really *don't* know anything about you other than
the fact you have a username/password combo suitable for SMTP-authing
(which may indicate you also have a Gradwell email address, but which
doesn't indicate you're actually using it at this moment), they can't
necessarily trust the potentially-spoofed sender address. And (given the
rest of their rules on Backscatter prevention) they may well just decide
it's not worth the risk of sending the DSN there.

Of course, I could still be wrong (in the sense that Gradwell may have
tried to send something and it's been nuked by your other ISP) - but the
possibility is there, nonetheless.

>
>> The problem of backscatter is now rife on the internet, to the extent
>> that (good) mailservers are generally quite careful about whom they
>> send failure-notifications.
>>
>> At the risk of teaching granny to suck eggs, here's why:
>>
>> Imagine that I forge a billion SPAM messages with a 'from' (and
>> envelope-from') Roy@roysdomain and inject them into an open relay or
>> (using a hijacked PC) even a closed, customer-only relay such as
>> Gradwell's,
>
> My modest account with Gradwell allows 100 emails a day. Seeing that, I
> think they would not worry about swamping me with backscatter, even if
> my AUTH password had been stolen and misused.

TBH, I think they would. Backscattering these days will get their
servers blacklisted - and yes, there are nutty list-maintainers out
there who test for this behaviour, and blacklist if they find culprits.
There is a quite well-known blacklist at http://www.backscatterer.org/ -
though in my view, you'd be mad to use this purely for
message-rejection, although positive hits from there *might* make for
useful datapoints in spam *detection*, but not rejection.

IMHO, Gradwell probably take backscatter quite seriously and prevent it,
as do most ISPs these days - but I am only guessing based up on their
reputation.

TTFN
--
Neil

[Neil Jackson]

Forgive me - I must add a rider to that last, otherwise perfect, paragraph:

"...but only if the MAIL FROM address given is a mailbox address
regarded as local to the [Gradwell] mailserver that received the
termination & reason."

Reason being, if it creates and sends an email notification to any
*non-local* address, that message *may* be considered backscatter. This
practice is now a no-no in most respectable corners of the net.

See http://spamlinks.net/prevent-secure-backscatter.htm#reject

--
Neil

[Simon Turner]

On Tuesday, in article
<slrnkb9por...@mymachine.invalid> ba...@o2.co.uk

"Brian" wrote:

> On 27-11-2012, Simon Turner <si...@twoplaces.co.uk> wrote:
>
> > On Monday, in article
> > <slrnkb7468...@mymachine.invalid> ba...@o2.co.uk
> > "Brian" wrote:

[...]

> >> I can tell my MTA not to use mx5.demon.co.uk and mx6.demon.co.uk. I can
> >> also instruct my MUA to have ba...@o2.co.uk as the envelope from. The
> >> MTA gets no further than its friend telnet did. Now what does it do?
> >>
> >> It has been informed by the Demon MTA about openspf so it does the
> >> decent thing and returns the mail with this information in it. Guess
> >> where to? That's correct! To ba...@o2.co.uk. This is an account I rarely
> >> look at.
> >
> > But, outside your artificial test, the envelope-from is the real sender,
> > who presumably looks at their mail less rarely. 8-) (Modulo unmonitored
> > sending accounts, of course.)
>
> I was concerned to point that it was possible to have incoming mail to a
> Demon account subjected to SPF even though SPF was turned off for the
> account itself. I thought the technique was quite neat, myself.

Indeed, it was a nice demonstration of that. I probably read too much
into your "an account I rarely look at" and assumed you were trying to
make a different point; apologies.

> And it
> also confirmed the sending MTA sent a message to the envelope from.

As it jolly well should! 8-)

[Simon Turner]

On Tuesday, in article <z7E6jvPBbQtQFw3W@x.x>
Roy_now_fre...@acanthus.demon.co.uk "Roy Brown"
wrote:

> In message <20121127.17...@twoplaces.co.uk>, Simon Turner
> <si...@twoplaces.co.uk> writing at 17:58:02 in his/her local time
> opines:-

> >Do you also have a domain with Gradwell, or do you just buy their relay

> >service? [...]

>
> No, I don't have a domain there. I once found myself using my Turnpike
> in an Internet cafe in Spain where the owner declined to tell me the
> outgoing SMTP address (it's all AUTH over there, even for your own ISP,
> so he wasn't going to tell me a password!), and I declined to use the
> webmail services that were keeping everyone else there happy.
>
> I had Gradwell outgoing SMTP inside 30 minutes without ever talking to a
> human - very slick.

I've been a big fan of Gradwell for many years; their assorted
"value-added" services work well, are reasonably priced, and are
wonderfully easy to set up and administer via their web site. I've
never yet needed an SMTP relay service (I almost never send mail from
outside my own network), but if I do, there's never been any doubt who I
would go to.

[Simon Turner]

On Tuesday, in article
<slrnkbaghj...@mymachine.invalid> ba...@o2.co.uk

"Brian" wrote:

> On 27-11-2012, Neil Jackson <ja...@techno.demon.co.uk.invalid> wrote:
>
> > 'silently-accepting-then-deleting-and-possibly-doing-a-bounce-message'
> > which would've been plain mad). I still don't agree with the policy in
> > terms of its level of rejection, but it's implementation in terms of its
> > method of rejection is at least 'normal').
>
> It makes you wonder, doesn't it? I can understand Demon offering SPF
> checking as a service but why was the decision made that
>
> (a) It should be compulsory,
> (b) Hardfails should not be allowed to be delivered?

[snip excellent exploration of the Demonic mindset]

The tragedy is that more and more ISPs seem to be taken in by the false
promises of SPF; and the forthcoming DMARC is only going to make it
worse, AFAICS.

One of my domain hosts decided to implement SPF a few years ago (an
early adopter!), without telling anyone, and rejected messages on any
kind of failure -- even a softfail! Their supposedly-technical support
people (both first- and second-tier) then tried to claim (a) that it
wasn't them doing the rejection, it was Hotmail; then (b) that SPF was
an Internet Standard and they had no choice about implementing it,
"because Hotmail want us to". It took a long and technical rant,
explaining in minute detail how wildly misinformed their tech support
people were, before one of their sysadmins got in touch and agreed with
everything I had said, opted me out of the SPF checking (which had
always been an available option), and went off to impart some clue to
their support staff.

[Simon Turner]

On Wednesday, in article <v0dts.451794$GX.2...@fx01.am4>
ja...@techno.demon.co.uk.invalid "Neil Jackson" wrote:

> [...] I have a feeling that mx5 and mx6 will

> probably point to mailservers 'inside the circled wagons' - i.e. ones
> that would normally still be reached, but only after the SPF-checkers
> had handled the message first.

Quite possibly, but I hope not: mx5/6 advertise a lower ESMTP SIZE limit
than mx2! (mx1 is currently unresponsive on port 25, as it has been --
from here, anyway -- for the last few days.)

mx2:
250-mdfmta002.tch.inty.net
250-PIPELINING
250-SIZE 52428800

mx5:
250-mdfmta011.tbr.inty.net
250-PIPELINING
250-SIZE 35000000

mx6:
250-mdfmta11.tch.inty.net
250-PIPELINING
250-SIZE 35000000

If Neil is right about mx5/6 being further along the normal route for
mail, it might be possible for mx2 to accept a message that will later
turn out to be too big to be processed...

In passing, note the further inconsistency in the hostnames: 002/011 for
mx2/mx5, but just 11 for mx6. (mx1 also uses the NNN format IIRC.)

I never like inconsistency in system setup. It can speak volumes.

[Simon Turner]

On Wednesday, in article <FBdts.657441$9H4.2...@fx17.am4>

ja...@techno.demon.co.uk.invalid "Neil Jackson" wrote:

> On 27/11/2012 14:07, Roy Brown wrote:
> > In message <0K1ts.368823$Wc4....@fx10.am4>, Neil Jackson
> > <ja...@techno.demon.co.uk.invalid> writing at 11:46:04 in his/her local
> > time opines:-
> >
> > <snip>
> >
> >> However, because you weren't calling from Gradwell's internal network,
> >> AND possibly because you weren't using Gradwell sender-address (you
> >> were using a k****.co.uk one), they can't be sure you're not a spoof
> >> yourself - so may have just decided not to send you any notification
> >> of Demon's rejection at all. Playing safe, to avoid backscatter.
> >
> > I used authentication with Gradwell. They might not be able to be sure
> > it wasn't a spoof, but I think prudence dictates they should assume it
> > isn't.
>
> It's easy to think that SMTP-auth is a pretty strong determinant that a
> user's From address is likely to be good and safe - but it can come down
> to the order of precedence of other trust-factors that Gradwell might
> have decided upon. If, for example, they believe that 'being on their
> local net and having one of their IP addresses' is king, then that may
> be the only factor involved. IMHO, most likely it's the fact that the
> sender-domain you used was non-local to Gradwell, so (even though they
> had your SMTP-auth details) they couldn't guarantee that any DSN would
> go to a local mailbox user. And that means it's a backscatter-risk.

Gradwell's SMTP relay service is not the usual ISP outgoing mail relay:
it's a standalone service sold to people to use in exactly the way Roy
is using it. It *expects* to be used from anywhere on the planet, and
(because it's sold as a standalone service to people with no other
connection to Gradwell) Gradwell cannot know anything about whether
e-mail addresses are yours to use or not.

Gradwell aren't a normal ISP: they have always provided extra goodies to
go with your existing (non-Gradwell) Net connection, rather than just
offering connectivity with extras thrown in (as most ISPs do). IIRC,
their "adding value" services like SMTP relay significantly predate the
availability of Internet connectivity from them.

> Of course, I could still be wrong (in the sense that Gradwell may have
> tried to send something and it's been nuked by your other ISP) - but the
> possibility is there, nonetheless.

In general, I agree, and it's good to make the point: but this case is
different.

Anyway, the mystery is now solved: having done some tests with Roy
yesterday, we now know that Gradwell *do* send a DSN when Demon reject
their relay attempt (good), but any-mail then refuse to accept it (bad).

Any-mail seem to have misconfigured their MDaemon server (either that,
or MDaemon is buggy, which seems less likely), as they mistakenly reject
Roy's address as invalid or expired:

<- 220-mail.any-mail.co.uk ESMTP MDaemon 12.0.4; Tue, 27 Nov 2012 18:59:55 +0000
<- 220-ANY-Mail has a zero tolerance policy in respect
<- 220-of spam and all transactions and IP addresses are logged
<- 220 *
-> EHLO ****.org.uk
<- 250-mail.any-mail.co.uk Hello ****.org.uk, pleased to meet you
<- 250-ETRN
<- 250-AUTH=LOGIN
<- 250-AUTH LOGIN CRAM-MD5
<- 250-8BITMIME
<- 250-STARTTLS
<- 250 SIZE 30000000
-> MAIL FROM:<>
<- 250 <>, Sender ok
-> RCPT TO:<****@****.co.uk>
<- 550 Backscatter Protection detected an invalid or expired email address

Nice. 8-(

[Neil Jackson]

On 28/11/2012 10:49, Simon Turner wrote:

>
> If Neil is right about mx5/6 being further along the normal route for
> mail, it might be possible for mx2 to accept a message that will later
> turn out to be too big to be processed...

ROFL. My hypothesis arose from a discussion in the forum where, in a
roundabout way, I guessed-at the demon 'wagon-train' and suggested an
injection 'later downstream' might be feasible to skip SPF. Days later,
the mx5/6 approach suddenly became an option. I am putting two and two
together and making four-and-a-half, possibly; for all I know, each of
the four boxes may simply be individual portals into the 'train', and
the other backhaul machines take care of the different jobs (like SPF,
routing, etc).

It would be extremely funny (in a non-funny sort of way) if the wagons
in the train had smaller capacities as the content goes further down the
line! I wouldn't put it past them... might even be worth a test... :)

>
> In passing, note the further inconsistency in the hostnames: 002/011 for
> mx2/mx5, but just 11 for mx6. (mx1 also uses the NNN format IIRC.)
>
> I never like inconsistency in system setup. It can speak volumes.

Yup. Volumes. Like 'our SMTPs go up to eleven', Spinal Tap fashion :)

I agree - inconsistency smacks of sketchy design or random post-fup*
patching. (*this has nothing to do with the fair usage policy, btw). :)

--
Neil

[Neil Jackson]

On 28/11/2012 11:14, Simon Turner wrote:

> Gradwell's SMTP relay service is not the usual ISP outgoing mail relay:
> it's a standalone service sold to people to use in exactly the way Roy
> is using it. It *expects* to be used from anywhere on the planet, and
> (because it's sold as a standalone service to people with no other
> connection to Gradwell) Gradwell cannot know anything about whether
> e-mail addresses are yours to use or not.

Don't confuse 'location' (anywhere on the planet; and encumbent
non-Gradwell IP address) with 'local mailbox' status. IMHO, if Gradwell
was sending on behalf of a Gradwell mailbox user, then a DSN would be
fine; OTOH, if the envelope-from could not be connected with a local
mailbox, backscatter is a risk, if DSNs are sent there.

The only possible rider is whether SMTP-auth constitutes enough of a
connection to a 'local mailbox' to satisfy Gradwell that backscatter
isn't a problem.

From your evidence later, I'd say this must be the key. Otherwise
Gradwell would've found themselves repeatedly in the backscatterer.org
blacklists by now. Maybe they are? <shrugs> I've not checked... :)

>
> Gradwell aren't a normal ISP: they have always provided extra goodies to
> go with your existing (non-Gradwell) Net connection, rather than just
> offering connectivity with extras thrown in (as most ISPs do). IIRC,
> their "adding value" services like SMTP relay significantly predate the
> availability of Internet connectivity from them.
>
>> Of course, I could still be wrong (in the sense that Gradwell may have
>> tried to send something and it's been nuked by your other ISP) - but the
>> possibility is there, nonetheless.
>
> In general, I agree, and it's good to make the point: but this case is
> different.

Acknowledged now. Thanks, as ever, for taking the time to test this for
Roy (and me, academically!)

>
> Anyway, the mystery is now solved: having done some tests with Roy
> yesterday, we now know that Gradwell *do* send a DSN when Demon reject
> their relay attempt (good), but any-mail then refuse to accept it (bad).
>
> Any-mail seem to have misconfigured their MDaemon server (either that,
> or MDaemon is buggy, which seems less likely), as they mistakenly reject
> Roy's address as invalid or expired:
>
> <- 220-mail.any-mail.co.uk ESMTP MDaemon 12.0.4; Tue, 27 Nov 2012 18:59:55 +0000
> <- 220-ANY-Mail has a zero tolerance policy in respect
> <- 220-of spam and all transactions and IP addresses are logged
> <- 220 *
> -> EHLO ****.org.uk
> <- 250-mail.any-mail.co.uk Hello ****.org.uk, pleased to meet you
> <- 250-ETRN
> <- 250-AUTH=LOGIN
> <- 250-AUTH LOGIN CRAM-MD5
> <- 250-8BITMIME
> <- 250-STARTTLS
> <- 250 SIZE 30000000
> -> MAIL FROM:<>
> <- 250 <>, Sender ok
> -> RCPT TO:<****@****.co.uk>
> <- 550 Backscatter Protection detected an invalid or expired email address
>
> Nice. 8-(
>

LOL - oh dear oh dear oh dear! I'm an MDaemon user of old, and I've not
seen this before firsthand, but I know what's wrong. MDaemon's got quite
a complex (optional) system for rejecting or marking potential
backscatter, but (as with all systems this complex) it has limitations.

IIRC, MDaemon's backscatter protection uses a system whereby an outgoing
message's 'Return-Path' header has a secret key hash appended to the
email envelope-from address. This means that if any DSNs are later
returned by mailservers further down the chain, they will be sent to
this semi-randomised email address, not the 'raw' email address. That
way, MDaemon *knows* this is a genuine DSN, not a bit of backscatter.

System works great - if all your outgoing email passes through the
MDaemon server first! But if, as in Roy's case, you plonk it into
Gradwell first, the envelope-from will never have the magic key in it,
and any DSN generated by a failure will be rejected by the MDaemon
(which lives at the MX address for the stated domain).

Let's see if I can explain it with examples...

First, this is the way it's *supposed* to work:

Roy sends a message from 'roy@k*.co.uk' to 'test@k*.demon.co.uk'. His
outgoing mailserver is Anymail's MDaemon box. This rewrites his
Return-Path: header and SMTP envelope-from as 'roy.1234567890@k*.co.uk'
(injecting the randomly-generated but uniquely secret-keyed 'backscatter
protection key' into his email address). The 'From' and/or 'Reply-To'
headers inside the message are left alone (because this is what real
people will reply to, later, and they generally won't see the
Return-Path header at all unless they look).

If Anymail were to send the message (using MX-lookup) to Demon, it
wouldn't bounce (because it would no longer fail Demon's SPF lookup of
the k*.co.uk domain and comparison with the Anymail server IP address).

So, for a giggle, lets assume they sent it to Gradwell first, just so we
can recreate what Roy did.

Gradwell would receive the connection from Anymail, and the
SMTP-envelope from would be 'roy.1234567890@k*.co.uk'. Gradwell would
accept it and hang up, and then try and send it on to Demon - but of
course, now it would fail Demon's SPF lookup and be rejected and hung-up
on there too. Gradwell would then need to generate a Delivery Service
Notification (bounce-message) to send back to 'roy.1234567890@k*.co.uk'.
The MX record on k*.co.uk points to the Anymail (MDaemon) server, and
the DSN is duly sent - with the usual 'blank' MAIL FROM: <> envelope
(because it's from Gradwell's machine, not a real person, and this is
the convention for DSNs), and with the RCPT TO: address of
'roy.1234567890@k*.co.uk'. Anymail see this is a DSN (by virtue of the
blank envelope-From ), and now expect to see a secret-keyed recipient...
and indeed, in this case, they get one. They can tally that backscatter
key with a recently generated outgoing email incident, and know that
this must be a genuine DSN. They can then accept it, and duly send it on
to 'roy@k*.co.uk' (undoing the 'key-insertion they performed earlier) at
his internal MDaemon mailbox (or theoretically, even offsite, if he is
forwarding onwards elsewhere).

It all works pretty well, *if* and *only if* Roy is sending out via
Anymail's server - i.e. using them as a smarthost.

In practice, here's what *actually* happened:

Roy sends a message from 'roy@k*.co.uk' to 'te...@place.d.c.u.'. His
outgoing mailserver is Gradwell. Gradwell accept the message for onward
delivery, placing 'roy@k*.co.uk' in the Return-Path and SMTP
envelope-from in the normal fashion. It fails Demon's SPF check (because
their IP doesn't match one listed in k*.co.uk's SPF) and is rejected
before its even transferred. Gradwell generate a DSN to 'roy@k*.co.uk'.
MX records for k*.co.uk point to Anymail, so Gradwell connect there to
send it. They begin SMTP transfer with MAIL FROM <> as normal, and
follow it up with RCPT TO: <roy@k*.co.uk>. At this point, Anymail says
"WTF? No backscatter key? This isn't one of ours. Goodbye!" and hangs up.

In a nutshell, by going via Gradwell, Roy is generating his own
backscatter! Anymail's backscatter protection is working as advertised,
but because he's not going out through their front door and getting his
hand stamped, they're not letting him back in! :)

Needless to say, I don't use backscatter protection on my own copy of
MDaemon - there are too many occasions when I might want to send mail
out via an alternative server than my own, so I have the luxury of just
not enabling this feature. I have used it once or twice with clients who
have MDaemon and who do *all* their outgoing mail via the company server
- and then it works just fine (and we have seen logs showing how it has
deflected a massive 'joe-job attempt on more than one occasion). But
with an ISP like Anymail, I can see why they simply turned this on by
default. They *may* have the option to turn it off, per domain,
possibly, so this might be worth enquiring about. IMHO, it's doubtful,
though. On my server it appears to be one set of keys for all domains
hosted there. All or nothing.

The reality is, it's yet another 'technique' for dealing with the
post-spam world - stuff that the SMTP standard never expected to
encounter and which it never made provision for. Rather like SPF (but
slightly less damaging) it can go wrong if circumvented or set up
incorrectly. But just like SPF and DKIM, if combined together with other
points of failure, it can take weeks to work out what holes in the Swiss
cheese all lined up at once - and by that time, the astronauts are dead! :(

At least we now know! Roy's option to avoid this, and the Demon
SPF-rejection of his SPF-protected k*.co.uk domain, is to use Anymail's
server as his outgoing mailserver for k*.co.uk. I would imagine that
he'll have (or they'll give him) a set of SMTP-auth details there, too,
as well as ports he should be able to use to reach the server from
virtually any other access point. MDaemon will do all the necessary
STARTTLS or SSL on IMAP4, POP3 and STMP, as you'd expect.

Alternatively, ditch Anymail completely, and have Gradwell host his
domain-name and mail backend for it.

Thanks so much Simon for finding the last jigsaw piece! :)

Cheers
--
Neil

[Simon Turner]

On Wednesday, in article <Miots.613429$Tf3.4...@fx12.am4>

ja...@techno.demon.co.uk.invalid "Neil Jackson" wrote:

> On 28/11/2012 11:14, Simon Turner wrote:
>
> > Gradwell's SMTP relay service is not the usual ISP outgoing mail relay:
> > it's a standalone service sold to people to use in exactly the way Roy
> > is using it. It *expects* to be used from anywhere on the planet, and
> > (because it's sold as a standalone service to people with no other
> > connection to Gradwell) Gradwell cannot know anything about whether
> > e-mail addresses are yours to use or not.
>
> Don't confuse 'location' (anywhere on the planet; and encumbent
> non-Gradwell IP address) with 'local mailbox' status.

My point was that Gradwell's "SMTP Outbound" service is fully
standalone: there is in general no local mailbox for it to be associated
with. SMTP AUTH is all they have.

[...]

> From your evidence later, I'd say this must be the key. Otherwise
> Gradwell would've found themselves repeatedly in the backscatterer.org
> blacklists by now. Maybe they are? <shrugs> I've not checked... :)

They don't appear to be (all my recent mail from Gradwell, including the
DSN they sent me yesterday at Roy's behest, came from 212.11.70.2 which
isn't in the list). I suspect there may be relatively few (and fairly
clueful) users of Gradwell's outbound relay, who are careful enough with
their systems and auth details that the spammers don't get in (or if
they do, it's very rare).

All ISPs seem to get blacklisted from time to time; AAISP were forced to
instigate a policy of not relaying DSNs through their outgoing relays
because of the number of instances of backscatter being perpetrated by
their customers. Sigh.

I would expect Demon to behave similarly to Gradwell if I used SMTP AUTH
to send mail from my twoplaces.co.uk domain via their servers,
connecting from the USA; I might try it sometime!

> > Anyway, the mystery is now solved: having done some tests with Roy
> > yesterday, we now know that Gradwell *do* send a DSN when Demon reject
> > their relay attempt (good), but any-mail then refuse to accept it (bad).

[...]

> LOL - oh dear oh dear oh dear! I'm an MDaemon user of old, and I've not
> seen this before firsthand, but I know what's wrong. MDaemon's got quite
> a complex (optional) system for rejecting or marking potential
> backscatter, but (as with all systems this complex) it has limitations.

[snip excellent explanation of MDaemon's backscatter protection]

> In a nutshell, by going via Gradwell, Roy is generating his own
> backscatter! Anymail's backscatter protection is working as advertised,
> but because he's not going out through their front door and getting his
> hand stamped, they're not letting him back in! :)

Nice summary! 8-)

> with an ISP like Anymail, I can see why they simply turned this on by
> default.

Only if they make it very clear to their customers that they MUST send
all outgoing mail via their servers or risk not seeing DSNs; I bet Roy
hadn't been told about this "feature" any more than he had been told
about them publishing SPF records for his domain. If I were any-mail, I
wouldn't have turned it on.

[...]

> Alternatively, ditch Anymail completely, and have Gradwell host his
> domain-name and mail backend for it.

That would be my reaction if I were in Roy's shoes.

[Neil Jackson]

On 28/11/2012 15:39, Simon Turner wrote:
> On Wednesday, in article <Miots.613429$Tf3.4...@fx12.am4>
> ja...@techno.demon.co.uk.invalid "Neil Jackson" wrote:
>
>> On 28/11/2012 11:14, Simon Turner wrote:
>>
>>> Gradwell's SMTP relay service is not the usual ISP outgoing mail relay:
>>> it's a standalone service sold to people to use in exactly the way Roy
>>> is using it. It *expects* to be used from anywhere on the planet, and
>>> (because it's sold as a standalone service to people with no other
>>> connection to Gradwell) Gradwell cannot know anything about whether
>>> e-mail addresses are yours to use or not.
>>
>> Don't confuse 'location' (anywhere on the planet; and encumbent
>> non-Gradwell IP address) with 'local mailbox' status.
>
> My point was that Gradwell's "SMTP Outbound" service is fully
> standalone: there is in general no local mailbox for it to be associated
> with. SMTP AUTH is all they have.

Understood - and in essence we're talking the same thing then... but
yes, if there are absolutely *no* local mailboxes, only SMTP Auth (which
cannot be connected to an email address when handling a DSN - there's no
login involved at that stage, I've since realised), then Gradwell's
relay must either (a) not care about backscatter or (b) have some other
means of determining whether to return a DSN to the Return-Path in the
event of a rejected SMTP transfer attempt.

>
> [...]
>> From your evidence later, I'd say this must be the key. Otherwise
>> Gradwell would've found themselves repeatedly in the backscatterer.org
>> blacklists by now. Maybe they are? <shrugs> I've not checked... :)
>
> They don't appear to be (all my recent mail from Gradwell, including the
> DSN they sent me yesterday at Roy's behest, came from 212.11.70.2 which
> isn't in the list). I suspect there may be relatively few (and fairly
> clueful) users of Gradwell's outbound relay, who are careful enough with
> their systems and auth details that the spammers don't get in (or if
> they do, it's very rare).

TBH, the users themselves will have no impact on whether Gradwell 'do'
backscatter. By that I mean, it doesn't matter whether their accounts
are watertight or not - it's not at their end where the backscatter
problem arises, it's at Gradwell's and how they respond to 'one-stage
removed' SMTP-transfer failures.

I'm guessing that because it's a relay-only server, it's never on the
receiving end of an MX record, so no inbound mail (to a Gradwell
mailbox) should ever find its way there. And presumably, no-one can
input a message for relay unless they have a valid SMTP auth. So any
attempt by outsiders to inject a message for a non-existent
gradwell-type address, could never happen, therefore, the opportunities
for Gradwell to generate backscatter are limited to:

(a) a user with a valid SMTP auth AND
(b) the same user giving a flawed/false/mistaken/spoofed MAIL FROM address
(c) the same user sending (RCPT TO) an unknown/non-existent offsite
address whose MX mailserver rejected the SMTP transaction. (or an SPF
failure as per Roy's)

I grant you, now that I know more about this particular Gradwell relay,
and the fact it has no local mailboxes at all, and will thus never
appear as a mailserver in MX, and won't relay at all unless SMTP-AUTHed,
I concede that it's probably *not* going to be a source of much
backscatter anyway, whether it has rules on the policy or not! :)

>
> All ISPs seem to get blacklisted from time to time; AAISP were forced to
> instigate a policy of not relaying DSNs through their outgoing relays
> because of the number of instances of backscatter being perpetrated by
> their customers. Sigh.
>
> I would expect Demon to behave similarly to Gradwell if I used SMTP AUTH
> to send mail from my twoplaces.co.uk domain via their servers,
> connecting from the USA; I might try it sometime!

Thinking it through (several times, and tying myself in knots as usual)
I tend to agree. Demon have (I think) a policy requiring all off-net IP
or non-local senders to use SMTP-Auth. That alone narrows all relay work
down to either 'trusted local senders' or 'trusted remote senders', so
they'll take as read the validity of all return-paths (because nothing
else can get in to the stream). I think. :)

There is the same marginal risk of backscatter arising, but only if a
'trusted' user spoofs his return-path in such a way that would cause the
DSN to end up in someone else's box. A limited likelihood unless a user
was misbehaving or careless (in which case they'd likely be warned,
because the corresponding SMTP-Authed or local non-authed incoming
transaction could probably be fished out of the logs and identified to a
'trusted' customer account). It might still get Demon temporarily in the
backscatter RBLs (but imho, only an idiot would use that RBL for
rejection, as I said. Datapoints is fine; rejection is dumb).

>
>>> Anyway, the mystery is now solved: having done some tests with Roy
>>> yesterday, we now know that Gradwell *do* send a DSN when Demon reject
>>> their relay attempt (good), but any-mail then refuse to accept it (bad).
>
> [...]
>
>> LOL - oh dear oh dear oh dear! I'm an MDaemon user of old, and I've not
>> seen this before firsthand, but I know what's wrong. MDaemon's got quite
>> a complex (optional) system for rejecting or marking potential
>> backscatter, but (as with all systems this complex) it has limitations.
>
> [snip excellent explanation of MDaemon's backscatter protection]
>
>> In a nutshell, by going via Gradwell, Roy is generating his own
>> backscatter! Anymail's backscatter protection is working as advertised,
>> but because he's not going out through their front door and getting his
>> hand stamped, they're not letting him back in! :)
>
> Nice summary! 8-)

Thanks.

>
>> with an ISP like Anymail, I can see why they simply turned this on by
>> default.
>
> Only if they make it very clear to their customers that they MUST send
> all outgoing mail via their servers or risk not seeing DSNs; I bet Roy
> hadn't been told about this "feature" any more than he had been told
> about them publishing SPF records for his domain. If I were any-mail, I
> wouldn't have turned it on.

Absolutely agree with everything you say. IMHO, this is sorta what I
fear Demon turning into, lately. Have kit (albeit borrowed in Demon's
case now), and sans clue how to set it up, or set policy on it, or
inform anyone how it's set. Just let them all find out the hard way, and
argue for changes (or leave) later on.

On a slightly different tack, I am still not entirely clear how Anymail
can create a DNS TXT record that doesn't show up when one does a 'dig'
at the domain requesting records of type 'ALL', yet have that TXT record
show up (with it's SPF conten) when doing a 'dig' for *just* records of
type TXT. It must be a DNS-server fault of some kind, but I've never
seen its like before!

PEBKAC, as they say.
:)

>
> [...]
>> Alternatively, ditch Anymail completely, and have Gradwell host his
>> domain-name and mail backend for it.
>
> That would be my reaction if I were in Roy's shoes.

Seconded.

--
Neil

[Roy Brown]

In message <UJrts.340189$Xv.1...@fx07.am4>, Neil Jackson
<ja...@techno.demon.co.uk.invalid> writing at 17:20:51 in his/her local
time opines:-

>On 28/11/2012 15:39, Simon Turner wrote:
>> On Wednesday, in article <Miots.613429$Tf3.4...@fx12.am4>
>> ja...@techno.demon.co.uk.invalid "Neil Jackson" wrote:
>>
>>> On 28/11/2012 11:14, Simon Turner wrote:
>>>
>>>> Gradwell's SMTP relay service is not the usual ISP outgoing mail relay:
>>>> it's a standalone service sold to people to use in exactly the way Roy
>>>> is using it. It *expects* to be used from anywhere on the planet, and
>>>> (because it's sold as a standalone service to people with no other
>>>> connection to Gradwell) Gradwell cannot know anything about whether
>>>> e-mail addresses are yours to use or not.
>>>
>>> Don't confuse 'location' (anywhere on the planet; and encumbent
>>> non-Gradwell IP address) with 'local mailbox' status.
>>
>> My point was that Gradwell's "SMTP Outbound" service is fully
>> standalone: there is in general no local mailbox for it to be associated
>> with. SMTP AUTH is all they have.
>
>Understood - and in essence we're talking the same thing then... but
>yes, if there are absolutely *no* local mailboxes, only SMTP Auth
>(which cannot be connected to an email address when handling a DSN -
>there's no login involved at that stage, I've since realised), then
>Gradwell's relay must either (a) not care about backscatter or (b) have
>some other means of determining whether to return a DSN to the
>Return-Path in the event of a rejected SMTP transfer attempt.

I suspect that they care about backscatter, but trust the users of their
service not to generate it, and would contact me if they got pushback
about any mail I sent that 'went awry'.

>>> From your evidence later, I'd say this must be the key. Otherwise
>>> Gradwell would've found themselves repeatedly in the backscatterer.org
>>> blacklists by now. Maybe they are? <shrugs> I've not checked... :)

>> They don't appear to be (all my recent mail from Gradwell, including the
>> DSN they sent me yesterday at Roy's behest, came from 212.11.70.2 which
>> isn't in the list). I suspect there may be relatively few (and fairly
>> clueful) users of Gradwell's outbound relay, who are careful enough with
>> their systems and auth details that the spammers don't get in (or if
>> they do, it's very rare).

Yep.

>TBH, the users themselves will have no impact on whether Gradwell 'do'
>backscatter. By that I mean, it doesn't matter whether their accounts
>are watertight or not - it's not at their end where the backscatter
>problem arises, it's at Gradwell's and how they respond to 'one-stage
>removed' SMTP-transfer failures.

>I'm guessing that because it's a relay-only server, it's never on the
>receiving end of an MX record, so no inbound mail (to a Gradwell
>mailbox) should ever find its way there. And presumably, no-one can
>input a message for relay unless they have a valid SMTP auth. So any
>attempt by outsiders to inject a message for a non-existent
>gradwell-type address, could never happen, therefore, the opportunities
>for Gradwell to generate backscatter are limited to:

>(a) a user with a valid SMTP auth AND

me

>(b) the same user giving a flawed/false/mistaken/spoofed MAIL FROM address

no, I gave a valid email address that I am entitled to use

>(c) the same user sending (RCPT TO) an unknown/non-existent offsite
>address whose MX mailserver rejected the SMTP transaction. (or an SPF
>failure as per Roy's)

yes

>I grant you, now that I know more about this particular Gradwell relay,
>and the fact it has no local mailboxes at all, and will thus never
>appear as a mailserver in MX, and won't relay at all unless
>SMTP-AUTHed, I concede that it's probably *not* going to be a source of
>much backscatter anyway, whether it has rules on the policy or not! :)

Yes.

>> I would expect Demon to behave similarly to Gradwell if I used SMTP AUTH
>> to send mail from my twoplaces.co.uk domain via their servers,
>> connecting from the USA; I might try it sometime!

>Thinking it through (several times, and tying myself in knots as usual)
>I tend to agree. Demon have (I think) a policy requiring all off-net IP
>or non-local senders to use SMTP-Auth. That alone narrows all relay
>work down to either 'trusted local senders' or 'trusted remote
>senders', so they'll take as read the validity of all return-paths
>(because nothing else can get in to the stream). I think. :)

I suppose I could use Demon for this. Back in the day, you couldn't use
SMTP AUTH; you had to be connected, by dial-up or broadband, to them,
and I almost never was.

>There is the same marginal risk of backscatter arising, but only if a
>'trusted' user spoofs his return-path in such a way that would cause
>the DSN to end up in someone else's box. A limited likelihood unless a
>user was misbehaving or careless (in which case they'd likely be
>warned, because the corresponding SMTP-Authed or local non-authed
>incoming transaction could probably be fished out of the logs and
>identified to a 'trusted' customer account). It might still get Demon
>temporarily in the backscatter RBLs (but imho, only an idiot would use
>that RBL for rejection, as I said. Datapoints is fine; rejection is dumb).

>>>> Anyway, the mystery is now solved: having done some tests with Roy
>>>> yesterday, we now know that Gradwell *do* send a DSN when Demon reject
>>>> their relay attempt (good), but any-mail then refuse to accept it (bad).

Indeed so,

>> [snip excellent explanation of MDaemon's backscatter protection]

>>> In a nutshell, by going via Gradwell, Roy is generating his own
>>> backscatter! Anymail's backscatter protection is working as advertised,
>>> but because he's not going out through their front door and getting his
>>> hand stamped, they're not letting him back in! :)

It depends how you define backscatter; for me, it's mail that is
returned elsewhere than where it was originated.

But if any-mail hadn't rejected the mail, and had simply put it in the
mailbox it was addressed to, then I would have picked it up, recognised
it as something I'd sent out, and not backscatter.

And realised the SPF problem a hell of a lot earlier than I did.

>>> with an ISP like Anymail, I can see why they simply turned this on by
>>> default.

>> Only if they make it very clear to their customers that they MUST send
>> all outgoing mail via their servers or risk not seeing DSNs; I bet Roy
>> hadn't been told about this "feature" any more than he had been told
>> about them publishing SPF records for his domain.

Correct.

>> If I were any-mail, I wouldn't have turned it on.

>Absolutely agree with everything you say. IMHO, this is sorta what I
>fear Demon turning into, lately. Have kit (albeit borrowed in Demon's
>case now), and sans clue how to set it up, or set policy on it, or
>inform anyone how it's set. Just let them all find out the hard way,
>and argue for changes (or leave) later on.

>>> Alternatively, ditch Anymail completely, and have Gradwell host his
>>> domain-name and mail backend for it.

>> That would be my reaction if I were in Roy's shoes.
>Seconded.

The problem is, it's a domain that looks as if it belongs to my company,
but Any-Mail are (sort of) cybersquatting on it, but not quite blatantly
enough for me to take it to ICANN.

However, Any-Mail offer free email addresses at the domain, so I've
partially reclaimed it back, for email, at least, by using some :-)

And up until now I've just used their service, and it's not been a
problem at all.

However, given all the trouble, and Any-mail's general inability to get
very much of this right, I've just contacted them to offer a small sum
of money if they will kindly transfer the domain to me.

I'm not holding my breath, though.

[Paul Wolff]

In message <4JAU3PcHamtQFw17@x.x>, Roy Brown
<Roy_now_fre...@acanthus.demon.co.uk> writes

>
>The problem is, it's a domain that looks as if it belongs to my
>company, but Any-Mail are (sort of) cybersquatting on it, but not quite
>blatantly enough for me to take it to ICANN.

Nominet, for .co.uk domains.

>
>However, Any-Mail offer free email addresses at the domain, so I've
>partially reclaimed it back, for email, at least, by using some :-)
>
>And up until now I've just used their service, and it's not been a
>problem at all.
>
>However, given all the trouble, and Any-mail's general inability to get
>very much of this right, I've just contacted them to offer a small sum
>of money if they will kindly transfer the domain to me.
>
>I'm not holding my breath, though.

Among the factors that weigh in these kinds of situation (domain dispute
resolution procedures) are owning a registered tm for the domain name,
and being asked a money premium to transfer it. As well as being the
first with the name, of course.

<http://www.nominet.org.uk/disputes/when-use-drs/policy-and-procedure/drs
-policy>
--
Paul