Mail delivery problem / greylisting / retry time exceeded
David Gibson
Demon) to Gradwell's mail server where it is - understandably - being
rejected with a 450 greylisted message. However, Demon appears not to be
retrying with much commitment, and swiftly sends me a mail rejected
notice, e,g.
My message was sent at...
Date: Sun, 26 Apr 2009 15:11:54 +0100
The rejection from Demon was...
Subject: Mail delivery failed: returning message to sender
Message-Id: <E1Ly57s-...@lon1-post-3.mail.demon.net>
Date: Sun, 26 Apr 2009 14:14:36 +0000
SMTP error from remote mail server after RCPT TO: ****
host mail-in-1.lb.gradwell.net [193.111.201.38]:
450 Recipient <***> greylisted - please see http://www.gradwell.com/
greylisted [th-mail-b0114]:
retry timeout exceeded
... so "retry timeout exceeded" seems a little premature, really.
What's gone wrong here? Who needs kicking? Demon?
--
David Gibson
Spam-cloaked message: The Reply-to: address *is* valid.
Richard Clayton
<david@[127.0.0.1]> writes
>Several times over the last few days I have tried to send mail (via
>Demon) to Gradwell's mail server where it is - understandably - being
>rejected with a 450 greylisted message.
Not understandable at all -- as soon as Gradwell has temporarily
rejected one email from Demon's servers it should then notice that this
email has been retried. Repeating this exercise on further email from
the same source is not only futile (the server will always retry, so it
is clearly not a dumb spambot) but also consumes resources at both ends
of the connection, causes delay, and is generally a Bad Thing To Do.
Gradwell is generally perceived of as being a company with "clue", but
apparently not in this case :(
> However, Demon appears not to be
>retrying with much commitment
It's more complex than that -- you'll be running into another problem
caused by an Exim optimisation....
> retry timeout exceeded
>
>... so "retry timeout exceeded" seems a little premature, really.
since Demon's end is well aware that all of the emails are going to the
same place, the Exim mailserver that it uses treats them as a group, and
there is now one email that has timed out; so all of the emails to the
same destination are also timed out :( This is usually the correct
thing to do and ensures that undeliverable email does not clutter up
queues to no purpose.
>What's gone wrong here? Who needs kicking? Demon?
Gradwell IMNSHO, their greylisting approach is unfit for purpose :(
--
richard writing to inform and not as company policy
"Assembly of Japanese bicycle require great peace of mind" quoted in ZAMM
Cadbury Moose
>
> In article <laDPAzD6...@mcrosolv.demon.co.uk>, David Gibson
> <david@[127.0.0.1]> writes
>
> >Several times over the last few days I have tried to send mail (via
> >Demon) to Gradwell's mail server where it is - understandably - being
> >rejected with a 450 greylisted message.
>
> Not understandable at all -- as soon as Gradwell has temporarily
> rejected one email from Demon's servers it should then notice that this
> email has been retried. Repeating this exercise on further email from
> the same source is not only futile (the server will always retry, so it
> is clearly not a dumb spambot) but also consumes resources at both ends
> of the connection, causes delay, and is generally a Bad Thing To Do.
>
> Gradwell is generally perceived of as being a company with "clue", but
> apparently not in this case :(
That depends on how well Demon is retrying. If it's queueing it and not
attempting redelivery before the receiving server forgets the initial
attempt (or it retries from a different IP address) it will get
greylisted
again. Lather, rinse, repeat.
> > However, Demon appears not to be
> >retrying with much commitment
>
> It's more complex than that -- you'll be running into another problem
> caused by an Exim optimisation....
>
> > retry timeout exceeded
> >
> >... so "retry timeout exceeded" seems a little premature, really.
>
> since Demon's end is well aware that all of the emails are going to the
> same place, the Exim mailserver that it uses treats them as a group, and
> there is now one email that has timed out; so all of the emails to the
> same destination are also timed out :( This is usually the correct
> thing to do and ensures that undeliverable email does not clutter up
> queues to no purpose.
I have experienced "instant" timeout from Demon in the past. (Also mail
being warehoused for several _weeks_ between retry attempts.)
> >What's gone wrong here? Who needs kicking? Demon?
>
> Gradwell IMNSHO, their greylisting approach is unfit for purpose :(
<polite silence>
Greylisting is not (IMAO) a particularly friendly tool. It will cut
spam from the "open outgoing mail chute and excrete regardless of
response" spambots, but anything that does proper retry (or is
ramming it through a real mailserver via compromised end users)
is likely to get it through.
After the "fun and games" a few weeks ago (greylisting between
Demon and BT/Yahoo) in which mail in either direction was subject
to random delays up to 36 hours, while mail from other (cough)
sources arrived almost instantly, I started shifting services
off Demon. The Webmail 'timeout' was the final straw and mail is
now firmly ensconced on Gradwell and not experiencing any
problems (so far). Also Squirrelmail is a _vast_ improvement
over the Demon Webmail offering.
Your Mailage May Vary, of course. 3:O)>
Cadbury Moose (now with added squirrel).
--
"There are some complaints that money can't buy. For everything else,
there's BastardCard. Accepted everywhere, especially with mallets."
-- Inquisitor in nan-ae
David Gibson
in <demon.service>, on Mon, 27 Apr 2009
Richard Clayton <ric...@highwayman.com> writes
>>What's gone wrong here? Who needs kicking?
>
>Gradwell IMNSHO, their greylisting approach is unfit for purpose :(
OK. Thanks. Ive been away for a few days and, on my return, there was
another batch of "retry time exceeded" messages in my in box. I havent
had a chance to look at them yet.
I had trouble with Gradwell's greylisting once before: it seemed that
they were treating every unique IP address as a different source [*].
The result was un-necessary delays to mails.
[*] which is (is in not?) daft when mail from an ISP can arrive with a
range of IP addresses, and a valid mail from one address in the range
should imply a valid mail from any address within (a suitable) range.
(Well, I expect its a bit more complicated than that :-(
My knowledge of these matters is not great. Could someone clear up a
query? When a rejection says "retry time exceeded", as in...
>A message that you sent could not be delivered to one or more of its
>recipients. This is a permanent error. The following address(es)
>failed:
>
> {***}
> SMTP error from remote mail server after RCPT TO:{***}:
> host mail-in-2.lb.gradwell.net [193.84.87.106]:
> 450 Recipient {***} greylisted - please see http://www.gradwell.com/
> greylisted [sh-virus-4]:
> retry timeout exceeded
... which machine is saying "retry timeout exceeded"? My understanding
was that Demon has received the 450 "greylisted" message and was
reporting that fact, and adding "retry timeout exceeded", essentially
saying "I have received this rejection and Im not trying again".
Is that right, or is Gradwell saying "retry time exceeded"?
hugh
<david@[127.0.0.1]> writes
beyond me.
However in the last week or so some e-mails sent have failed to arrive
and today I received a 450 error message.
I am aware that a lot of spam is sent out in my domain name. I had a
problem with spamcop some time ago but got in touch and asked them to
"whitelist" (is that the correct term* my (static) IP address which they
must have done as up til now I've had no further problems.
What can I do about it?
--
hugh
It may be more complicated but is it better?
Richard Clayton
<hugh@[127.0.0.1]> writes
>However in the last week or so some e-mails sent have failed to arrive
>and today I received a 450 error message.
>
>I am aware that a lot of spam is sent out in my domain name. I had a
>problem with spamcop some time ago but got in touch and asked them to
>"whitelist" (is that the correct term* my (static) IP address which they
>must have done as up til now I've had no further problems.
>
>What can I do about it?
post the error message if you want people to do anything more than guess
hugh
<ric...@highwayman.com> writes
>In article <HMjzbFGs...@raefell.demon.co.uk>, hugh
><hugh@[127.0.0.1]> writes
>
>>However in the last week or so some e-mails sent have failed to arrive
>>and today I received a 450 error message.
>>
>>I am aware that a lot of spam is sent out in my domain name. I had a
>>problem with spamcop some time ago but got in touch and asked them to
>>"whitelist" (is that the correct term* my (static) IP address which they
>>must have done as up til now I've had no further problems.
>>
>>What can I do about it?
>
>post the error message if you want people to do anything more than guess
>
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
yyy...@staffssearchandrescue.org
SMTP error from remote mail server after RCPT
TO:<yy...@staffssearchandrescue.org>:
host mail.staffssearchandrescue.org [88.208.194.18]:
450 <xx...@raefell.co.uk>: Sender address rejected:
Domain not found: retry timeout exceeded
------ This is a copy of the message, including all the headers. ------
Return-path: <xx...@raefell.co.uk>
Received: from raefell.demon.co.uk ([80.177.121.199])
by anchor-post-2.mail.demon.net with esmtp (Exim 4.69)
id 1LwICm-0007m7-m4
for yyy...@staffssearchandrescue.org; Tue, 21 Apr 2009 15:48:17
+0000
Message-ID: <bsj0TZA6...@raefell.demon.co.uk>
Date: Tue, 21 Apr 2009 16:47:06 +0100
To: "Simon Rose, Staffordshire Search & Rescue Team."
<yyy...@staffssearchandrescue.org>
From: Hugh Emerson <xx...@raefell.co.uk>
Reply-To: xx...@raefell.co.uk
Subject: Re: Fwd: tyres donated to SSART
References: <Nkd5F3kQ8Z...@mail.thetopofahill.com>
<DE900CDF-92BD-4A2E...@staffssearchandrescue.org>
In-Reply-To:
<DE900CDF-92BD-4A2E...@staffssearchandrescue.org>
MIME-Version: 1.0
Content-Type: text/plain;charset=us-ascii;format=flowed
User-Agent: Turnpike/6.02-M (<esszrH$f+5azXHLfW4I8Q7hGsl>)
Sender (me) changed to xxxxx and recipient changed to yyyyy
I've also sent this to abuse@demon
Richard Clayton
<hugh@[127.0.0.1]> writes
>This message was created automatically by mail delivery software.
always nice to have the headers, but this apparently comes from Demon's
mailserver
>A message that you sent could not be delivered to one or more of its
>recipients. This is a permanent error. The following address(es) failed:
>
> yyy...@staffssearchandrescue.org
> SMTP error from remote mail server after RCPT
>TO:<yy...@staffssearchandrescue.org>:
> host mail.staffssearchandrescue.org [88.208.194.18]:
> 450 <xx...@raefell.co.uk>: Sender address rejected:
the MX for staffsearchandrescue.org is 88.208.194.18 which appears to be
a machine at fasthosts.net.uk
It has said that it temporarily cannot accept your email...
> Domain not found: retry timeout exceeded
... but similar temporary events have been going on for some time for
this destination, and so Exim has decided to give up.
>Received: from raefell.demon.co.uk ([80.177.121.199])
> by anchor-post-2.mail.demon.net with esmtp (Exim 4.69)
> id 1LwICm-0007m7-m4
> for yyy...@staffssearchandrescue.org; Tue, 21 Apr 2009 15:48:17
>+0000
I note this is 10 days ago... you'd think their temporary problem would
be fixed by now!!
... however, as others have suggested, they may have implemented a
greylisting scheme. viz: they reject email on the first time of asking
because dumb spambots give up. However, clever spambots do not (so it's
not all that much help these days) and they may have foolishly
configured a short memory for what is a retry --- hard to say, ring up
the recipient and get them to discuss the issue with their ISP!
>Sender (me) changed to xxxxx and recipient changed to yyyyy
>I've also sent this to abuse@demon
In principle abuse@ can try and educate the recipient about how best to
configure greylisting (or indeed suggest which range of IP addresses to
whitelist since greylisting real mail systems is a complete waste of
time). However, your best bet is to get your correspondent. who is
actually spending money (!) to do the complaining. Their ISP is
essentially not delivering :(
Richard Clayton
<david@[127.0.0.1]> writes
>I had trouble with Gradwell's greylisting once before: it seemed that
>they were treating every unique IP address as a different source [*].
that's sane, but if you include the sender and receiver and make a
5-tuple then that isn't :(
>My knowledge of these matters is not great. Could someone clear up a
>query? When a rejection says "retry time exceeded", as in...
>
>> retry timeout exceeded
>
>... which machine is saying "retry timeout exceeded"?
Demon's (he says, making assumptions about the provenance of the email!
please post headers unless you _know_ it's not necessary!)
hugh
<ric...@highwayman.com> writes
the only instance in which I have actually received an error message but
I know other e-mails have not got through.
David Gibson
Richard Clayton <ric...@highwayman.com> writes
[DG]
>>I had trouble with Gradwell's greylisting once before: it seemed that
>>they were treating every unique IP address as a different source [*].
>
>that's sane, but if you include the sender and receiver and make a
>5-tuple then that isn't :(
Gradwell claims to use a triple of (IIRC OTTOMH) sender, receiver and
IP.
>>... which machine is saying "retry timeout exceeded"?
>
>Demon's (he says, making assumptions about the provenance of the email!
>please post headers unless you _know_ it's not necessary!)
Well, here's a copy of the message that prompted my original query.
(Some headers omitted, that are not relevant)
The salient points (AIUI) are that the message left my machine and was
accepted by Demon at Sun, 26 Apr 2009 14:14:21. But by Sun, 26 Apr 2009
14:14:36 Demon was returning it to me, reporting Gradwell's 450
rejection. The message "retry timeout exceeded" seemed a little odd,
given the short timescale involved.
What I was asking (apologies if this was unclear) is which machine made
the decision that the retry timeout had been exceeded? My understanding
was that this was Demon, after getting fed up with 450s. But Demon seems
to have acted over-enthusiastically, issuing that message after only 15
minutes.
But perhaps other factors are involved? I have had six or seven of these
messages in the last week, some arriving very promptly, like this
example, and some taking several days to be returned to me. So "over
enthusiasm" is not the common factor.
----- message begins -----
Received: from pop3.demon.co.uk by mcrosolv.demon.co.uk with POP3
id <1Ly5F2-0q2000-...@pop3.demon.co.uk>
for <mcro...@pop3.demon.co.uk> ; Sun, 26 Apr 2009 15:24:19 +0100
Return-Path: <>
Received: from punt3.mail.demon.net by mailstore
for {***}@mcrosolv.demon.co.uk id 1Ly5F2-0q2000-08-9ih;
Sun, 26 Apr 2009 14:22:00 +0000
Received: from [194.217.242.77] (lhlo=anchor-hub.mail.demon.net)
by punt3.mail.demon.net with lmtp id 1Ly5F2-0q2000-08
for {***}@mcrosolv.demon.co.uk; Sun, 26 Apr 2009 14:22:00 +0000
Received: from [193.111.201.43] (helo=th-mail-b0119.gradwell.net)
by anchor-hub.mail.demon.net with esmtp id 1Ly5F1-0004G1-RB
for {***}@mcrosolv.demon.co.uk; Sun, 26 Apr 2009 14:21:59 +0000
X-AntiVirus-Gradwell: Scanned for viruses by th-mail-b0119.gradwell.net
(1/1 scanners operating) [Sun, 26 Apr 2009 15:21:37 +0100]
X-Gradwell-Mailfilter: SpamAssassin hits were RDNS_NONE [Sun, 26 Apr
2009 15:21:35 +0100] [rule id 5646 (default-spam)]
X-Gradwell-Mailfilter: Not Spam, SpamAssassin [79.135.125.30] hits of
0.1 (5 required) [Sun, 26 Apr 2009 15:21:35 +0100] [rule id 5646
(default-spam)]
Delivered-To: forwarding-{***}
Received: from lon1-bounce-1-e1000g399003.mail.thus.net
([194.217.241.113] helo=lon1-bounce-1.mail.thus.net country=GB)
by th-mail-b0119.gradwell.net with esmtp (Gradwell gwh-smtpd
1.290) id 49f46dec.7c5b.4e
for {***}; Sun, 26 Apr 2009 15:21:32 +0100
(envelope-sender <>)
Received: from lon1-post-3.mail.demon.net (lon1-post-3.mail.demon.net
[195.173.77.150])
by lon1-bounce-1.mail.thus.net (Postfix) with ESMTP id 3FBEF611C
for <{***}>; Sun, 26 Apr 2009 14:14:36 +0000 (UTC)
Received: from exim by lon1-post-3.mail.demon.net with local (Exim 4.69)
id 1Ly57s-0002m7-dQ
for {***}; Sun, 26 Apr 2009 14:14:36 +0000
X-Failed-Recipients: {***}
Reply-To: postm...@demon.net
Auto-Submitted: auto-replied
From: Mail Delivery System <Mailer...@lon1-post-3.mail.demon.net>
To: {***}
Subject: Mail delivery failed: returning message to sender
Message-Id: <E1Ly57s-...@lon1-post-3.mail.demon.net>
Date: Sun, 26 Apr 2009 14:14:36 +0000
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
{***}
SMTP error from remote mail server after RCPT TO:{***}:
host mail-in-1.lb.gradwell.net [193.111.201.38]:
450 Recipient {***} greylisted - please see http://www.gradwell.com/
greylisted [th-mail-b0114]:
retry timeout exceeded
------ This is a copy of the message, including all the headers. ------
Return-path: {***}
Received: from mcrosolv.demon.co.uk ([83.104.168.235])
by lon1-post-3.mail.demon.net with esmtp (Exim 4.69)
id 1Ly57d-0002l2-ef; Sun, 26 Apr 2009 14:14:21 +0000
Message-ID: <UbXTAWCq...@mcrosolv.demon.co.uk>
Date: Sun, 26 Apr 2009 15:11:54 +0100
To: {***}
Cc: {***}
From: {***}
Sender: {***}
Subject: {***}
[snip]
----- message ends-----
Thanks for all assistance.
David Gibson
David Gibson <david@[127.0.0.1]> writes
>But Demon seems
>to have acted over-enthusiastically, issuing that message after only 15
>minutes.
Umm. I mean 15 seconds. Brain not functioning at this time of day.
Kate Brown
>In article <laDPAzD6...@mcrosolv.demon.co.uk>, David Gibson
><david@[127.0.0.1]> writes
>
>>Several times over the last few days I have tried to send mail (via
>>Demon) to Gradwell's mail server where it is - understandably - being
>>rejected with a 450 greylisted message.
I've had a number of these 'retry timeout exceeded' bounces in the past
couple of days, nothing to do with Gradwell, as far as I know. What's
really, really annoying is that these messages are weeks old, so that
I've been assuming people have received them, and they haven't. I've
resent them and am just hoping this time they'll get through, but will
be very cross if in another few weeks time I get another 'retry timeout
exceeded' bounce. And why should 'greylisted for 5 minutes' in the last
instance result in a two-week delay in bouncing?
Is there anything to be done about it? Here are some headers from three
rejects. I have asterisked some letters in recipients and not included
the top few headers as they are just the forwarding through pipex to
demon, nothing odd there. There doesn't seem to be anything common to
all three. What is X-CNFS-Analysis?
Received: from exim by lon1-post-2.mail.demon.net with local (Exim 4.69)
id 1LyznI-0007CS-bR
for santa...@cockaigne.org.uk; Wed, 29 Apr 2009 02:45:08 +0000
X-Failed-Recipients: d***@desertdawn.net
Reply-To: postm...@demon.net
Auto-Submitted: auto-replied
From: Mail Delivery System <Mailer...@lon1-post-2.mail.demon.net>
To: santa...@cockaigne.org.uk
Subject: Mail delivery failed: returning message to sender
Message-Id: <E1LyznI-...@lon1-post-2.mail.demon.net>
Date: Wed, 29 Apr 2009 02:45:08 +0000
X-CNFS-Analysis: v=1.0 c=1 a=AKOq_jAOYJoA:10 a=vAEB7g6cr4oA:10
a=GMbZalcY608A:10 a=khhf3mMRAAAA:8 a=lrifNNj3AAAA:8 a=U7UbAiMzAAAA:8
a=e5JM5sMwAAAA:8 a=_qs4uYpxAAAA:8 a=208-QhAbAAAA:8 a=aWE4pLrzAAAA:8
a=GcH3OUrB3k-PJlGxwpUA:9 a=n4x9zETmVwd2HO892cAA:7
a=JYSkPs13V5QP2UJbIlK3scJkXA4A:4 a=nVRoR-c7szIA:10 a=76XYHKbIq94A:10
a=vZ9RFRgr9M0A:10 a=oTUuC4HcWgQA:10 a=ufcFtqpOvzwA:10 a=MO3xX2F5pXgA:10
a=O94jgkEeAd4A:10 a=kwi05-_JsMAA:10 a=nMf8nYl5Q1xW5I_X:21
a=MjlCS95jp6ajOftU:21
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
d***@desertdawn.net
retry timeout exceeded
------ This is a copy of the message, including all the headers. ------
------ The body of the message is 12113814 characters long; only the
first
------ 24576 or so are included here.
Return-path: <santa...@cockaigne.org.uk>
Received: from quartano.demon.co.uk ([62.49.19.230]
helo=newcockaigne.demon.co.uk)
by lon1-post-2.mail.demon.net with esmtp (Exim 4.69)
id 1LuQNX-000513-Zo; Thu, 16 Apr 2009 12:13:12 +0000
Message-ID: <7J3XsJI3...@newcockaigne.demon.co.uk>
Date: Thu, 16 Apr 2009 13:06:15 +0100
********************
Received: from exim by lon1-post-3.mail.demon.net with local (Exim 4.69)
id 1Lzl4W-0001GH-fd
for santa...@cockaigne.org.uk; Fri, 01 May 2009 05:14:04 +0000
X-Failed-Recipients: ivo***@redemeta.com.br,
jw***@cs.washington.edu
Reply-To: postm...@demon.net
Auto-Submitted: auto-replied
From: Mail Delivery System <Mailer...@lon1-post-3.mail.demon.net>
Subject: Mail delivery failed: returning message to sender
Message-Id: <E1Lzl4W-...@lon1-post-3.mail.demon.net>
Date: Fri, 01 May 2009 05:14:04 +0000
X-CNFS-Analysis: v=1.0 c=1 a=AKOq_jAOYJoA:10 a=vAEB7g6cr4oA:10
a=GMbZalcY608A:10 a=wBO6qJBTAAAA:8 a=lrifNNj3AAAA:8 a=U7UbAiMzAAAA:8
a=e5JM5sMwAAAA:8 a=_qs4uYpxAAAA:8 a=208-QhAbAAAA:8 a=aWE4pLrzAAAA:8
a=XpFHPPw_ZRA34IVEHCUA:9 a=zMyJNb5h45BQruSymQgA:7
a=w1qKAaf-5vu7uJM3qUWScG4Pf7oA:4 a=nVRoR-c7szIA:10 a=76XYHKbIq94A:10
a=vZ9RFRgr9M0A:10 a=oTUuC4HcWgQA:10 a=ufcFtqpOvzwA:10 a=MO3xX2F5pXgA:10
a=kwi05-_JsMAA:10 a=Mhvc5CHPcRhiN52c:21 a=AdbBqjyy9XyEy6GT:21
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
ivo***@redemeta.com.br
retry timeout exceeded
jw***@cs.washington.edu
SMTP error from remote mail server after RCPT
TO:<jwa...@cs.washington.edu>:
host mxa2.cs.washington.edu [128.208.2.116]: 451 4.3.2 Please try
again later:
retry timeout exceeded
------ This is a copy of the message, including all the headers. ------
------ The body of the message is 360881 characters long; only the first
------ 24576 or so are included here.
Return-path: <santa...@cockaigne.org.uk>
Received: from quartano.demon.co.uk ([62.49.19.230]
helo=newcockaigne.demon.co.uk)
by lon1-post-3.mail.demon.net with esmtp (Exim 4.69)
id 1LulFJ-0000gM-f3; Fri, 17 Apr 2009 10:24:42 +0000
Message-ID: <5VMrR+GH...@newcockaigne.demon.co.uk>
Date: Fri, 17 Apr 2009 11:24:07 +0100
********************************
Received: from exim by lon1-post-2.mail.demon.net with local (Exim 4.69)
id 1M06HH-0000mk-aj
for hel...@cockaigne.org.uk; Sat, 02 May 2009 03:52:39 +0000
X-Failed-Recipients: n*****@neiljenkins.com
Reply-To: postm...@demon.net
Auto-Submitted: auto-replied
From: Mail Delivery System <Mailer...@lon1-post-2.mail.demon.net>
To: hel...@cockaigne.org.uk
Subject: Mail delivery failed: returning message to sender
Message-Id: <E1M06HH-...@lon1-post-2.mail.demon.net>
Date: Sat, 02 May 2009 03:52:39 +0000
X-CNFS-Analysis: v=1.0 c=1 a=AKOq_jAOYJoA:10 a=vAEB7g6cr4oA:10
a=GMbZalcY608A:10 a=Ng0Qb3MOAAAA:8 a=NYPpvbjNAAAA:8 a=lrifNNj3AAAA:8
a=U7UbAiMzAAAA:8 a=e5JM5sMwAAAA:8 a=l0ploK0ZAAAA:8
a=3D9qAIiM5QHUtsqzzNAA:9 a=0RE2cLQf8jd4-8SdFmsA:7
a=5tnAawece10w8kWgQ5kaHP1NYswA:4 a=95ieUySXwL8A:10 a=8MXIyxiTokMA:10
a=ZxgEG6RK0qC2WzdK:21 a=hwvS4G7JL8wL-SwT:21
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
SMTP error from remote mail server after RCPT
To:<n******@neiljenkins.com>:
host mx1.freeola.net [62.249.192.195]: 450 <ne...@neiljenkins.com>:
Recipient address rejected: Greylisted for 5 minutes:
retry timeout exceeded
------ This is a copy of the message, including all the headers. ------
Return-path: <hel...@cockaigne.org.uk>
Received: from quartano.demon.co.uk ([62.49.19.230]
helo=newcockaigne.demon.co.uk)
by lon1-post-2.mail.demon.net with esmtp (Exim 4.69)
id 1LvsBA-0006t2-bX; Mon, 20 Apr 2009 12:00:52 +0000
Message-ID: <k3oRRNGz...@newcockaigne.demon.co.uk>
Date: Mon, 20 Apr 2009 12:59:47 +0100
To: <n*****@neiljenkins.com>
--
Kate B
PS 'elvira' is spamtrapped - please reply to 'elviraspam' at cockaigne dot org dot uk if you
want to reply personally
Nick Holloway
> In article "Mail delivery problem / greylisting / retry time exceeded"
> in <demon.service>, on Fri, 1 May 2009
> Richard Clayton <ric...@highwayman.com> writes
>
> [DG]
> >>I had trouble with Gradwell's greylisting once before: it seemed that
> >>they were treating every unique IP address as a different source [*].
> >
> >that's sane, but if you include the sender and receiver and make a
> >5-tuple then that isn't :(
>
> Gradwell claims to use a triple of (IIRC OTTOMH) sender, receiver and
> IP.
A popular greylisting solution is Postgrey, and this uses the 3-tuple
of client IP/sender/recipient[1]. You have the implied server IP for
a 4-tuple.
From Richard's earlier description, Exim is making the decision globally
across all messages sharing the same destination IP. This is a 2-tuple
of client IP/server IP.
This pretty much means that Demon's mail servers delivering to mail
servers using Postgrey (or similar) with sufficient range of new
sender/recipient pairs will return some messages with "Retry timeout
exceeded" prematurely.
--
`O O' | Nick.H...@pyrites.org.uk
// ^ \\ | http://www.pyrites.org.uk/
Richard Clayton
<Nick.H...@pyrites.org.uk> writes
>From Richard's earlier description, Exim is making the decision globally
>across all messages sharing the same destination IP. This is a 2-tuple
>of client IP/server IP.
correct (see the Exim documentation)
>This pretty much means that Demon's mail servers delivering to mail
>servers using Postgrey (or similar) with sufficient range of new
>sender/recipient pairs will return some messages with "Retry timeout
>exceeded" prematurely.
that shouldn't happen if some messages are accepted...
but my suggestion remains imparting clue to Gradwell... it's not as if
they will never have heard of Demon!
David Gibson
Richard Clayton <ric...@highwayman.com> writes
>In article <762ls7F...@mid.individual.net>, Nick Holloway
><Nick.H...@pyrites.org.uk> writes
>
>>From Richard's earlier description, Exim is making the decision globally
>>across all messages sharing the same destination IP. This is a 2-tuple
>>of client IP/server IP.
>
>correct (see the Exim documentation)
So ... can I just check if I am understanding this correctly?
1) I send a message via Demon to a destination via Gradwell. Demon tries
to send the message but receives a 450 response from Gradwell. Demon
(Exim) then has to decide whether and when to try again.
2) Demon finds that mail to Gradwell has been subject to a "retry
timeout exceeded" action in the "recent" past (for some value of
"recent") so Demon decides it would be better to reject my message
immediately.
Am I right up to this point?
Obviously I want to try and sort out this problem Im experiencing, but
its still not clear to me whether this is a Demon fault or a Gradwell
fault. I cannot - with my limited understanding - see any evidence to
determine which machine is at fault.
Gradwell say that their triplet comprises
1. The IP address of the host attempting the delivery.
2. The envelope sender address
3. The envelope recipient address.
And that "when a given triplet is first seen, it will be whitelisted in
our database 10 minutes after first being seen, this is then sent out to
all our mailservers which can take a further 5-10 minutes to finish
synchronising. If no mail has been accepted on a given triplet within 24
hours after being whitelisted, the entry is removed, meaning the triplet
goes back to the initial "greylisted" state. If mail is accepted, the
entry is updated accordingly, and will be removed 7 days after the LAST
mail was received from a given correspondent. So if you receive mail
from a given triplet at least once a week, the entry should never be
removed"
... which seems fine to me :-). Is anyone here saying that there is
evidence that Gradwell's machine is *not* doing that?
For my part, I would suggest that a likely cause of the problem is mail
being stuck at Demon - i.e. Demon is not trying again within 24 hours.
I say that because Im now seeing more mail rejections and, unlike the 15
second example I posted here, the latest ones are being delayed for many
days.
Example 1 - this was stuck at Demon for 13 days before being accepted by
Gradwell and *delivered* (!?) to the recipient
Received: from lon1-post-3.mail.demon.net ([195.173.77.150] country=GB)
by sov-mail-b0024.gradwell.net with esmtp (Gradwell gwh-smtpd 1.290)
id 49fc02b7.50a0.9 for ***@***; Sat, 2 May 2009 09:22:15 +0100
(envelope-sender <***@***>)
Received: from mcrosolv.demon.co.uk ([83.104.168.235]) by lon1-post-
3.mail.demon.net with esmtp (Exim 4.69) id 1LvWtk-0005yi-dR for
***@***; Sun, 19 Apr 2009 13:17:28 +0000
Example 2 - This was stuck at Demon for 5 days before being returned
with a "450 ...retry timeout" message.
Received: from mcrosolv.demon.co.uk ([83.104.168.235]) by anchor-post-
2.mail.demon.net with esmtp (Exim 4.69) id 1Lxh3E-0004Cx-lp; Sat, 25
Apr 2009 12:32:12 +0000
returned as...
From: Mail Delivery System <Mailer...@anchor-post-2.mail.demon.net>
Subject: Mail delivery failed: returning message to sender
Message-Id: <E1Lzd23-...@anchor-post-2.mail.demon.net>
Date: Thu, 30 Apr 2009 20:38:59 +0000
>but my suggestion remains imparting clue to Gradwell... it's not as if
>they will never have heard of Demon!
Sorry for not understanding this, but Im not quite sure what it is that
you think Gradwell should be doing that they arent. Once I *do* know I
can tell them :-)
Richard Clayton
<david@[127.0.0.1]> writes
>In article "Mail delivery problem / greylisting / retry time exceeded"
>in <demon.service>, on Sat, 2 May 2009
>Richard Clayton <ric...@highwayman.com> writes
>
>>In article <762ls7F...@mid.individual.net>, Nick Holloway
>><Nick.H...@pyrites.org.uk> writes
>>
>>>From Richard's earlier description, Exim is making the decision globally
>>>across all messages sharing the same destination IP. This is a 2-tuple
>>>of client IP/server IP.
>>
>>correct (see the Exim documentation)
>
>So ... can I just check if I am understanding this correctly?
>
>1) I send a message via Demon to a destination via Gradwell. Demon tries
>to send the message but receives a 450 response from Gradwell. Demon
>(Exim) then has to decide whether and when to try again.
>
>2) Demon finds that mail to Gradwell has been subject to a "retry
>timeout exceeded" action in the "recent" past (for some value of
>"recent") so Demon decides it would be better to reject my message
>immediately.
roughly so, it's longer ago than "recent", but it's about _all_
deliveries to Gradwell, not just yours.
Retry behaviour is a common source of discussions on the Exim help
lists... the manual is a clear as ever :(
<URL:http://www.exim.org/exim-html-current/doc/html/spec_html/ch32.html#
SECID166>
>
>Am I right up to this point?
>
>Obviously I want to try and sort out this problem Im experiencing, but
>its still not clear to me whether this is a Demon fault or a Gradwell
>fault.
Gradwell is failing to accept email, on the theory that Demon's machines
have nothing better to do than to queue it up and try and send it again.
That theory has a number of flaws.
>I cannot - with my limited understanding - see any evidence to
>determine which machine is at fault.
Gradwell is treating Demon's systems as if they were botnet zombies.
That is IMNSHO clueless. There is absolutely no point whatsoever in
doing so. Trivial changes to their database recording retries would
automatically detect the nature of Demon's servers. Whitelisting these
servers would also fix the problem.
>Gradwell say that their triplet comprises
>
>1. The IP address of the host attempting the delivery.
>2. The envelope sender address
>3. The envelope recipient address.
>
>And that "when a given triplet is first seen, it will be whitelisted in
>our database 10 minutes after first being seen, this is then sent out to
>all our mailservers which can take a further 5-10 minutes to finish
>synchronising.
At any given time it is quite likely that failures are being seen for
deliveries to Gradwell's machine since Demon's machines do not work with
triples in this way -- data is recorded only about each destination
host.
So at any given time it will be known that Gradwell's machines are
failing and optimisations occur which prevent the wasting of time trying
to deliver to a failing machine...
This could quite well be further complicated by any other rejections
occurring as email is delivered to Gradwell (eg people forwarding spam
there, which is rejected).
>>but my suggestion remains imparting clue to Gradwell... it's not as if
>>they will never have heard of Demon!
>
>Sorry for not understanding this, but Im not quite sure what it is that
>you think Gradwell should be doing that they arent.
Either they need to greylist by sending IP address only (because triples
don't make much sense when deliveries to them are coming through
machines such as Demon's post system), or they need to whitelist such
systems (which is probably simplest, because these types of machines are
always going to retry anyway, and holding up email at all in such
circumstances is entirely pointless).
Essentially, once you have seen a particular IP address retry, even just
once, greylisting anything at all from it for the next <n> days is dumb
> Once I *do* know I
>can tell them :-)
--
David Gibson
Richard Clayton <ric...@highwayman.com> writes
>Gradwell is treating Demon's systems as if they were botnet zombies.
>That is IMNSHO clueless. There is absolutely no point whatsoever in
>doing so. Trivial changes to their database recording retries would
>automatically detect the nature of Demon's servers. Whitelisting these
>servers would also fix the problem.
Thanks for your clear explanations, Richard. I think I understand it
now. I have something I can go to Gradwell with, although, for the time
being, I have switched off greylisting :-(
H o w e v e r ... :-) ... whilst accepting that Gradwell's greylisting
does appear to be rather dumb, and could do with some attention, I am
wondering if there is also a problem (possibly transient) at Demon,
which had triggered the behaviour I am seeing?
I mentioned in my last message that Demon appeared to be taking up to 13
days to do something with my mail. And just now, I have had a mail
rejection from Demon for a message I sent TEN days ago. This didnt go
anywhere near Gradwell, but it seems that it took 10 days for Demon to
reject it with...
>A message that you sent could not be delivered to one or more of its
>recipients. This is a permanent error. The following address(es)
>failed:
>
> ***@***.com
> SMTP error from remote mail server after RCPT TO:<***@***.com>:
> host mail.***.com [***]: 450 <***@***.com>: Recipient address
> rejected: Temporary failure. Please try again later.:
> retry timeout exceeded
So ... my tentative hypothesis is that WHILST badly-configured
greylisting might not be helping the situation, Demon has exposed the
problem due to a sluggish mail machine. As often: an event cascade.
Could that be the case? After all, we know that Demon mail IS sometimes
sluggish :-(
Richard Clayton
<david@[127.0.0.1]> writes
>Thanks for your clear explanations, Richard. I think I understand it
>now. I have something I can go to Gradwell with, although, for the time
>being, I have switched off greylisting :-(
That won't help you -- unless everyone turns off greylisting :(
[snip possible problem with trying to deliver for too long]
>So ... my tentative hypothesis is that WHILST badly-configured
>greylisting might not be helping the situation, Demon has exposed the
>problem due to a sluggish mail machine.
It's far from sluggish -- I peeked at the logs specially, and found that
six delivery attempts were made to Gradwell's MX machines within three
seconds of your email reaching post-3 (you'll have seen from the Exim
documentation I linked to earlier that an attempt will be made to
deliver a brand new email no matter what in case the remote machine is
discriminating against just one email). However all six machines
rebuffed the delivery with a 450 reply :(
David Gibson
in <demon.service>, on Mon, 4 May 2009
Richard Clayton <ric...@highwayman.com> writes
>I peeked at the logs specially, and found that
>six delivery attempts were made to Gradwell's MX machines within three
>seconds of your email reaching post-3 (you'll have seen from the Exim
>documentation I linked to earlier that an attempt will be made to
>deliver a brand new email no matter what in case the remote machine is
>discriminating against just one email). However all six machines
>rebuffed the delivery with a 450 reply :(
Ah. So ... Demon is trying to deliver, but Gradwell is (at the least)
taking too long to whitelist the messages. So, by the time Gradwell
decides to accept the mail, Demon has already backed off from its
delivery attempts, and so when Demon does try again hours later,
Gradwell has (Im guessing) timed out and treats it as a fresh message,
which it then rejects again.
... possibly.... :-)
OK. <sigh>. I'll tackle Gradwell.
Thanks very much for your patient assistance with this.
Darren Salt
> Richard Clayton <ric...@highwayman.com> writes
>> I peeked at the logs specially, and found that six delivery attempts were
>> made to Gradwell's MX machines within three seconds of your email reaching
>> post-3 (you'll have seen from the Exim documentation I linked to earlier
>> that an attempt will be made to deliver a brand new email no matter what
>> in case the remote machine is discriminating against just one email).
>> However all six machines rebuffed the delivery with a 450 reply :(
> Ah. So ... Demon is trying to deliver, but Gradwell is (at the least)
> taking too long to whitelist the messages. So, by the time Gradwell decides
> to accept the mail, Demon has already backed off from its delivery
> attempts, and so when Demon does try again hours later, Gradwell has (Im
> guessing) timed out and treats it as a fresh message, which it then rejects
> again.
> ... possibly.... :-)
Is it just *hours* later? Here's one, destination elsewhere, which got stuck:
Received: from anchor-post-1.mail.demon.net (anchor-post-1.mail.demon.net [195.173.77.132])
by liszt.debian.org (Postfix) with ESMTP id 4BA252D0C8D
for <debian...@lists.debian.org>; Mon, 4 May 2009 19:38:56 +0000 (UTC)
Received: from youmustbejoking.demon.co.uk ([80.176.152.238] helo=pentagram.youmustbejoking.demon.co.uk)
by anchor-post-1.mail.demon.net with esmtp (Exim 4.69)
id 1LyqQz-0001oZ-hR
for debian...@lists.debian.org; Tue, 28 Apr 2009 16:45:29 +0000
Exactly why that one was stuck for 6 days, I'd quite like to know...
Two messages which I sent on Saturday, both to other lists, are apparently
similarly stuck. I've seen no evidence of them having arrived and no evidence
of rejection; not even so much as notification of a transient problem. (I
resent one, adding a few CCs, and it got through without problem.)
--
| Darren Salt | d @ youmustbejoking | nr. Ashington, | Toon
| Debian GNU/Linux | s ,demon,co,uk | Northumberland | Army
| + Buy local produce. Try to walk or cycle. TRANSPORT CAUSES GLOBAL WARMING.
The Borg assimilated my race and all I got was this t-shirt.
Richard Clayton
<david@[127.0.0.1]> writes
>In article "Mail delivery problem / greylisting / retry time exceeded"
>in <demon.service>, on Mon, 4 May 2009
>Richard Clayton <ric...@highwayman.com> writes
>
>>I peeked at the logs specially, and found that
>>six delivery attempts were made to Gradwell's MX machines within three
>>seconds of your email reaching post-3 (you'll have seen from the Exim
>>documentation I linked to earlier that an attempt will be made to
>>deliver a brand new email no matter what in case the remote machine is
>>discriminating against just one email). However all six machines
>>rebuffed the delivery with a 450 reply :(
>
>Ah. So ... Demon is trying to deliver, but Gradwell is (at the least)
>taking too long to whitelist the messages.
nope -- greylisting theory says you do not whitelist in seconds; and
anyway these were retries to different machines [Gradwell offers lots of
alternatives]
So if you think that greylisting is the best thing since sliced bread
then there is nothing to take exception too...
.. main problem is that slicing takes so long that it all goes mouldy :(
>So, by the time Gradwell
>decides to accept the mail, Demon has already backed off from its
>delivery attempts, and so when Demon does try again hours later,
Demon didn't retry with your message, but attempted another message to
the same destination. When it was 4xx'd then Demon did not retry yours
because it thought it would be a waste of time :(
>OK. <sigh>. I'll tackle Gradwell.
>
>Thanks very much for your patient assistance with this.
--
David Gibson
Im still getting messages returned from Demon, after it has held on to
them for a couple of weeks or more; and people are still telling me that
they havent received my messages.
These messages are not going anywhere near Gradwell. And whilst it may
be (is? :-) the case that Gradwell's greylisting is inadequately set up,
this is not the common factor here. The common factor is Demon! Viz..
My message sent to the University of Manitoba...
> Date: Sun, 19 Apr 2009 18:31:13 +0100
And the first indication that they did not receive it when I had hoped
they would...
>Subject: Mail delivery failed: returning message to sender
>Message-Id: <E1M1yA3-...@lon1-post-1.mail.demon.net>
>Date: Thu, 07 May 2009 07:36:55 +0000
> SMTP error from remote mail server after end of data:
> host ***.umanitoba.ca [130.179.16.34]:
> 452 4.2.1 id n477asVQ027325 from 195.173.77.148 temporary embargo.
> retry timeout exceeded
I seem to recall that Demon used to helpfully report when it was having
rouble delivering a message. Does it not do that any more? Regardless
of which machine is "at fault" it is somewhat inconvenient for Demon to
hang onto a message for 19 days before spitting it back to me.
James Hoddinott
> Further information on the mail delivery problem I reported.
>
> Im still getting messages returned from Demon, after it has held on to
> them for a couple of weeks or more; and people are still telling me that
> they havent received my messages.
>
> These messages are not going anywhere near Gradwell. And whilst it may
> be (is? :-) the case that Gradwell's greylisting is inadequately set up,
> this is not the common factor here. The common factor is Demon! Viz..
The common factor is greylisting; it isn't a Demon-specific problem...
> My message sent to the University of Manitoba...
>
>> Date: Sun, 19 Apr 2009 18:31:13 +0100
>
> And the first indication that they did not receive it when I had hoped
> they would...
>
>> Subject: Mail delivery failed: returning message to sender
>> Message-Id: <E1M1yA3-...@lon1-post-1.mail.demon.net>
>> Date: Thu, 07 May 2009 07:36:55 +0000
>
>> SMTP error from remote mail server after end of data:
>> host ***.umanitoba.ca [130.179.16.34]:
>> 452 4.2.1 id n477asVQ027325 from 195.173.77.148 temporary embargo.
>> retry timeout exceeded
Can you submit reports to abuse@ please; this makes it a lot easier for
us to track such matters.
--
James Hoddinott
Manager, Network Abuse Team, THUS, a Cable&Wireless business
David Gibson
James Hoddinott <jam...@demon.net> writes
[DG]
>> The common factor is Demon!
>
>The common factor is greylisting; it isn't a Demon-specific problem...
But, as I said in my previous message ...
I seem to recall that Demon used to helpfully report when it was having
trouble delivering a message. Does it not do that any more? Regardless
of which machine is "at fault" it is somewhat inconvenient for Demon to
hang onto a message for 19 days before spitting it back to me.
>Can you submit reports to abuse@ please; this makes it a lot easier for
>us to track such matters.
Im happy to submit whatever's needed. I'll gather together a few
rejection reports and send them off.
Mike Edwards
I am experiencing exactly the same problems and most google searches
suggest that...
"The reason your mailserver is getting blocked is most likely that it
does not properly handle 45x SMTP error codes, and does not retry
delivery within a reasonable amount of time after receiving such a code."
Ultimately this suggests that there is an issue at Demon's end where
they should be retrying within a certain time frame.
David Gibson
in <demon.service>, on Fri, 8 May 2009
>I am experiencing exactly the same problems and most google searches
>suggest that...
>
>"The reason your mailserver is getting blocked is most likely that it
>does not properly handle 45x SMTP error codes, and does not retry
>delivery within a reasonable amount of time after receiving such a code."
>
>Ultimately this suggests that there is an issue at Demon's end where
>they should be retrying within a certain time frame.
For me, the issue has migrated somewhat. Whilst it may be the case that
the greylisters are at fault for acting dumbly (as Richard Clayton
suggested), or that there is some other issue at Demon, the real fact
for me, now, is that I am getting mail rejections from messages that I
sent three weeks ago and it would have been "helpful" (very helpful in
fact :-( if Demon had warned me earlier that it was having trouble
delivering them.
James Hoddinott <jam...@demon.net> wrote
>Can you submit reports to abuse@ please; this makes it a lot easier for us to
>track such matters.
... and so I sent them a batch of messages this afternoon. With an hour
I was receiving a "flood" of messages - probably two dozen by now -
comprising both rejections of messages sent by me and late deliveries of
messages sent to me. Is this coincidence or has someone at Demon
rattled something, I wonder? :-)
Les Desser
Edwards <mike.e...@rocksoft.demon.co.uk> Fri, 8 May 2009 14:05:47
writes
>Ultimately this suggests that there is an issue at Demon's end where
>they should be retrying within a certain time frame.
I think RC explained that the problem is that Demon is being clever. It
is looking at the totality of attempts to a specific delivery point not
just the history of a single email.
If too many rejections are received from IP a.d.c.d (based on attempted
delivery of many **different* emails) then *all* deliveries to a.b.c.d
are delayed.
This efficiency enhancement is counter-productive now that greylisting
has been introduced and needs to be removed or reviewed.
RC may be right that greylisting the Demon servers is pointless but the
facts are that mail is being delayed and something needs to be done to
fix it.
--
Les Desser
(The Reply-to address IS valid)
Chris Cooksey
<david@[127.0.0.1]> writes
>In article "Mail delivery problem / greylisting / retry time exceeded"
>in <demon.service>, on Fri, 8 May 2009
>Mike Edwards <mike.e...@rocksoft.demon.co.uk> writes
>
>>I am experiencing exactly the same problems and most google searches
>>suggest that...
>>
>>"The reason your mailserver is getting blocked is most likely that it
>>does not properly handle 45x SMTP error codes, and does not retry
>>delivery within a reasonable amount of time after receiving such a code."
>>
>>Ultimately this suggests that there is an issue at Demon's end where
>>they should be retrying within a certain time frame.
>
>
>James Hoddinott <jam...@demon.net> wrote
>>Can you submit reports to abuse@ please; this makes it a lot easier for us to
>>track such matters.
>
OK, done that.
It seems to have started 15 April and I have had several with various
45X error codes ...
Wed, 15 Apr 2009 09:29:40 +0100 451 4.7.1 Greylisting in action, please
come back in 00:10:00: retry timeout exceeded
Fri, 17 Apr 2009 14:20:26 +0100 451 4.7.1 Greylisting in action, please
come back later: retry timeout exceeded
Fri, 17 Apr 2009 14:20:26 +0100 451 4.3.2 Tempfail :Try again later,
please: retry timeout exceeded
Fri, 17 Apr 2009 09:45:25 +0100 451 4.4.3 Please try again later:
Fri, 17 Apr 2009 14:20:26 +0100 retry timeout exceeded
Fri, 17 Apr 2009 14:20:26 +0100 451 4.7.1 Greylisting in action, please
come back later: retry timeout exceeded
--
Chris Cooksey
Darren Salt
[snip]
> James Hoddinott <jam...@demon.net> wrote
>> Can you submit reports to abuse@ please; this makes it a lot easier for
>> us to track such matters.
> ... and so I sent them a batch of messages this afternoon. With an hour I
> was receiving a "flood" of messages - probably two dozen by now -
> comprising both rejections of messages sent by me and late deliveries of
> messages sent to me.
I've seen the same, though not as many.
> Is this coincidence or has someone at Demon rattled something, I wonder?
> :-)
By now, you probably have a message indicating the latter. (I do.)
--
| Darren Salt | d @ youmustbejoking | nr. Ashington, | Toon
| Debian GNU/Linux | s ,demon,co,uk | Northumberland | Army
| + RIPA NOTICE: NO CONSENT GIVEN FOR INTERCEPTION OF MESSAGE TRANSMISSION
The man who smiles when things go wrong has thought of who to blame it on.
David Gibson
in <demon.service>, on Fri, 8 May 2009
>James Hoddinott <jam...@demon.net> wrote
>>Can you submit reports to abuse@ please; this makes it a lot easier for us to
>>track such matters.
>
>... and so I sent them a batch of messages this afternoon. With an hour
>I was receiving a "flood" of messages - probably two dozen by now -
>comprising both rejections of messages sent by me and late deliveries of
>messages sent to me. Is this coincidence
:-) My messages didnt leave my PC due to a ... slight error. So,
coincidence, possibly, although...
> or has someone at Demon
>rattled something, I wonder? :-)
... this could still have happened, I guess.
Phil Masters
<News...@dessergroup.com> wrote:
>RC may be right that greylisting the Demon servers is pointless but the
>facts are that mail is being delayed and something needs to be done to
>fix it.
Part of the problem seems to be that Demon set up some new mail
servers - which of course they're perfectly entitled to do as a
routine operation. But the greylisters (who may normally let Demon
mail through by default) didn't recognise these new addresses, and
temporarily blocked them - which Demon arguably doesn't handle well.
Dunno how Demon or anyone else can tell the greylisters of the world
that they're adding new servers...
--
Phil Masters
* http://www.philm.demon.co.uk *
* http://philmasters.blogspot.com/ *
"The specific which you have discovered is an aid not
to memory, but to reminiscence, and you give your
disciples not truth, but only the semblance of truth;
they will be hearers of many things and will have
learned nothing; they will appear to be omniscient and
will generally know nothing; they will be tiresome
company, having the show of wisdom without the reality."
-- Plato anticipates geekdom, Wikipedia, and the Web.
Richard Clayton
<david@[127.0.0.1]> writes
>Whilst it may be the case that
>the greylisters are at fault for acting dumbly (as Richard Clayton
>suggested)
It is clearly the case that some servers are being dumb :(
>, or that there is some other issue at Demon
That's possible (though if so, I suspect it's a minority of the cases).
I've been looking closely at a couple of examples which are not so
easily explained as the bulk flows to Gradwell are :(
>James Hoddinott <jam...@demon.net> wrote
>
>>Can you submit reports to abuse@ please; this makes it a lot easier for us to
>>track such matters.
James will need to know which mail machine was involved and the unique
ID associated with the email (ie: you're going to need to send the
entirety of the "bounce message" including all the headers thereof)
David Gibson
in <demon.service>, on Fri, 8 May 2009
>>James Hoddinott <jam...@demon.net> wrote
>>
>>>Can you submit reports to abuse@ please; this makes it a lot easier for us to
>>>track such matters.
>
>James will need to know which mail machine was involved and the unique
>ID associated with the email (ie: you're going to need to send the
>entirety of the "bounce message" including all the headers thereof)
Yes, done that. I only removed the subject matter of the messages.
What is clear is that from mid-afternoon today something has got moving
and Im receiving a "flood" of mail rejections from messages I sent up to
three weeks ago. Colleagues are also reporting messages of mine from up
to three weeks ago, that have now arrived.
What is a little distressing is that some messages were "important".
All usual caveats understood of course: mail is fallible. :-(
hugh
<jam...@demon.net> writes
"It looks like either the recipient or the recipient's ISP has numerous
anti-spam measures in place. Quite why it gave a "Domain not found"
error I don't know. Perhaps it was having problems looking such this up
at the time.
I'd keep trying and also contact the recipient via alternative means to
have them look at it."
I am still experiencing this problem with non-delivery messages
appearing today from e-mails sent 16th April.
I have also contacted Fasthosts fort eh second time, the ISP involved
and have requested they white list my IP address. I am still awaiting a
response.
Ian
<david@[127.0.0.1]> writes
The host was "ncmail1.blackbaud.com".
This is a recent development, as my last email to the same recipient
went through on the 15th April.
I'll forward it to abuse@.
--
Ian
Molly Mockford
<ne...@youmustbejoking.demon.cu.invalid> wrote in
<505DBEBB78%ne...@youmustbejoking.demon.cu.invalid>:
>I demand that David Gibson may or may not have written...
>> Is this coincidence or has someone at Demon rattled something, I wonder?
>> :-)
>
>By now, you probably have a message indicating the latter. (I do.)
Any chance you could give us a hint as to what it says? I have been
watching this thread closely, since I have a particular client (on
Gradwell) who is complaining that mail to them from Demon, and *only*
from Demon, has been delayed by days on end or is totally failing to
arrive. All other mail, from all other mailservers, is arriving in a
timely fashion. It is clear that there is a clash between Demon's
delivery attempts, and Gradwell's greylisting (or presumably any
greylisting anywhere, but I wouldn't know about others); what I would
very much like to know is whether it is something which Demon say they
can fix and, if so, whether they say they intend to!
--
Molly Mockford
They that can give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety - Benjamin Franklin
(My Reply-To address *is* valid, though may not remain so for ever.)
James Hoddinott
> It is clear that there is a clash between Demon's
> delivery attempts, and Gradwell's greylisting (or presumably any
> greylisting anywhere, but I wouldn't know about others); what I would
> very much like to know is whether it is something which Demon say they
> can fix and, if so, whether they say they intend to!
The problem reported last Friday should be resolved now, at least for
any new mail being sent.
Anyone getting DSNs related to greylisting, and from mail they have sent
from Saturday onwards, should send the details on to abuse@ for further
investigation.
David Gibson
in <demon.service>, on Fri, 8 May 2009
>> Is this coincidence or has someone at Demon rattled something, I wonder?
>> :-)
>
>By now, you probably have a message indicating the latter. (I do.)
No, no message received. Perhaps its stuck somewhere? :-)
Although I note, in a later posting to this newsgroup...
James Hoddinott <jam...@demon.net> writes
>The problem reported last Friday should be resolved now, at least for any new
>mail being sent.
David Gibson
Molly Mockford <nospam...@mollymockford.me.uk> writes
>It is clear that there is a clash between Demon's
>delivery attempts, and Gradwell's greylisting (or presumably any
>greylisting anywhere, but I wouldn't know about others); what I would
>very much like to know is whether it is something which Demon say they
>can fix and, if so, whether they say they intend to!
I didnt get around to sending a message to sup...@gradwell.net,
outlining my problem. It seems, from what Richard Clayton was saying, as
if "someone" ought to gently point out to them that their grey-listing
is a little dumb. Now, I could do that, I suppose, but ... open
question to Demon staff ... is this not something that would better come
from you? Im just a nobody :-(
Mike Edwards
> > It is clear that there is a clash between Demon's
> > delivery attempts, and Gradwell's greylisting (or presumably any
> > greylisting anywhere, but I wouldn't know about others); what I would
> > very much like to know is whether it is something which Demon say they
> > can fix and, if so, whether they say they intend to!
>
> The problem reported last Friday should be resolved now, at least for
> any new mail being sent.
>
> Anyone getting DSNs related to greylisting, and from mail they have sent
> from Saturday onwards, should send the details on to abuse@ for further
> investigation.
Excellent news. Can we assume there is no more mail hanging around in
the system waiting to go from the past couple of weeks?
David Gibson
Kate Brown <elv...@nospam.demon.co.uk> writes
>What is X-CNFS-Analysis?
I believe this is added by Cloudmark
Ian Bell
>In article "Mail delivery problem / greylisting / retry time exceeded"
>in <demon.service>, on Sat, 2 May 2009
>Kate Brown <elv...@nospam.demon.co.uk> writes
>
>>What is X-CNFS-Analysis?
>
>I believe this is added by Cloudmark
The header is in fact added by the Demon mail system, but does contain
Cloudmark data.
--
Ian Bell THUS
a Cable&Wireless business