Cloudmark false positives?
Denis McMahon
shopping website, and while doing so, send emails from a website to
various dummy names at my demon host.
All the emails from the webserver to my demon host seem to go astray.
Emails from the webserver to other accounts are ok, and emails to the
demon accounts from other places are ok.
I suspect that cloudmark is tripping on false positives, which is a bit
worrying. Can I disable it for my account?
(Yes, I know I could look on the demon website, but finding information
there is becoming so tedious that I'm asking here first).
Rgds
Denis McMahon
Andy
<denis.m....@googlemail.com> wrote
>Hmm, I'm in the process of integrating a payment solution into a
>shopping website, and while doing so, send emails from a website to
>various dummy names at my demon host.
>
>All the emails from the webserver to my demon host seem to go astray.
>Emails from the webserver to other accounts are ok, and emails to the
>demon accounts from other places are ok.
>
>I suspect that cloudmark is tripping on false positives, which is a bit
>worrying. Can I disable it for my account?
Yes
>
>(Yes, I know I could look on the demon website, but finding information
>there is becoming so tedious that I'm asking here first).
>
http://knowledgebase.demon.net/article/email-filtering.html#optout
--
Andy Taylor [Editor, Austrian Philatelic Society].
Visit <URL:http://www.austrianphilately.com>
Denis McMahon
> In message <4ca89b52$0$6344$bed6...@gradwell.net>, Denis McMahon
> <denis.m....@googlemail.com> wrote
>> Hmm, I'm in the process of integrating a payment solution into a
>> shopping website, and while doing so, send emails from a website to
>> various dummy names at my demon host.
>>
>> All the emails from the webserver to my demon host seem to go astray.
>> Emails from the webserver to other accounts are ok, and emails to the
>> demon accounts from other places are ok.
>>
>> I suspect that cloudmark is tripping on false positives, which is a bit
>> worrying. Can I disable it for my account?
>
>
> Yes
>>
>> (Yes, I know I could look on the demon website, but finding information
>> there is becoming so tedious that I'm asking here first).
>>
> http://knowledgebase.demon.net/article/email-filtering.html#optout
Yeah, now wondering how long the optout takes to go into effect ... I'm
guessing anything between immediately and within 24 hours ...
If disabling is immediate, then I still don't know what's breaking these
emails.
Rgds
Denis McMahon
Andy
<denis.m....@googlemail.com> wrote
[
>Yeah, now wondering how long the optout takes to go into effect ... I'm
>guessing anything between immediately and within 24 hours ...
It's Sunday and raining, so probably not immediate...
You would perhaps notice when it does by increased volume of spam.
>
>If disabling is immediate, then I still don't know what's breaking these
>emails.
>
Have you a local rejection rule, possibly old, that they are triggering?
Denis McMahon
> In message <4ca8a414$0$6373$bed6...@gradwell.net>, Denis McMahon
> <denis.m....@googlemail.com> wrote
> [
>> Yeah, now wondering how long the optout takes to go into effect ... I'm
>> guessing anything between immediately and within 24 hours ...
>
> It's Sunday and raining, so probably not immediate...
>
> You would perhaps notice when it does by increased volume of spam.
>
>>
>> If disabling is immediate, then I still don't know what's breaking these
>> emails.
>>
> Have you a local rejection rule, possibly old, that they are triggering?
Client side filtering was the first thing I checked.
Rgds
Denis McMahon
Martin Brown
> Hmm, I'm in the process of integrating a payment solution into a
> shopping website, and while doing so, send emails from a website to
> various dummy names at my demon host.
Might be worth using Webmail to see if they actually reach Demons
servers and then get rejected during download. Old long forgotten
antispam reject rules unexpectedly triggering locally could give the
same symptoms when using dummy addresses.
> All the emails from the webserver to my demon host seem to go astray.
> Emails from the webserver to other accounts are ok, and emails to the
> demon accounts from other places are ok.
>
> I suspect that cloudmark is tripping on false positives, which is a bit
> worrying. Can I disable it for my account?
Cloudmark seems pretty well behaved wrt false positives. Unless your
shopping website is selling V1agra I'd not expect any problems.
Regards,
Martin Brown
John Hall
Martin Brown <|||newspam|||@nezumi.demon.co.uk> writes:
>Cloudmark seems pretty well behaved wrt false positives.
Agreed.
> Unless your shopping website is selling V1agra I'd not expect any
>problems.
I recall someone reporting a problem here a few years ago. It turned out
that the subject line of the email that had failed to arrive contained
the expression "via Gravesend". :)
--
John Hall
"I look upon it, that he who does not mind his belly,
will hardly mind anything else."
Dr Samuel Johnson (1709-84)
Denis McMahon
> In article <QUgqo.1216$HW3...@newsfe11.iad>,
> Martin Brown <|||newspam|||@nezumi.demon.co.uk> writes:
>> Cloudmark seems pretty well behaved wrt false positives.
>
> Agreed.
>
>> Unless your shopping website is selling V1agra I'd not expect any
>> problems.
>
> I recall someone reporting a problem here a few years ago. It turned out
> that the subject line of the email that had failed to arrive contained
> the expression "via Gravesend". :)
It's certainly not selling viagra.
However, I tried soime more testing, including sending a test email from
the server to 4 email addresses. The mail to the three non demon
addresses arrived almost instantly.
I've opened a ticket with fasthosts, including the server log entry for
the page get for the latest test, and the raw data of the successful
emails, as well as the code and output of the test page.
Also included a successfully received test email from my demon mailbox.
I've asked fasthosts to check their postfix logs to verify whether the
message (a) didn't reach (b) was received by or (c) wasn't accepted by a
demon inbound server.
If it was (a) then fasthosts need to tell my why the message appears to
have died in their system, as the postfix server that the PHP was
talking to accepted the mail and returned an "ok" status.
If it was (b) then I want a log entry showing the mail being handed to
demon by fasthosts. At that point, I will ask demon to explain where the
message went.
If it was (c), I hope that there's some explanation in the log entry
that will explain why demon rejected the mail.
Of course, in the old days someone from demon would jump on a post like
this and start digging to make sure there wasn't a problem at demon as
soon as they read it, but I suspect that the new demon isn't quite as
pro-active in such matters.
Rgds
Denis McMahon
Denis McMahon
follow up to myself, bad form etc, I know
However, I think I have solved the problem, it wasn't cloudmark.
The fasthosts hosting package user...@host.domain that was being used
for return-path and envelope-from in the postfix setup on the webserver
was resolving to a class a private address (10.x.x.x)
I suspect that demon was rejecting the message before it ever got to
cloudmark on the basis that the return-path / envelope from was invalid
because undeliverable / no mx entry.
Having modified my php to use " -f user...@host.domain " as the fifth
parameter on the call to the php mail() function, which appears to be
setting the return-path acceptably, the mails are now getting through.
Technically I think this is a fasthosts problem, although demon are
perhaps being a little enthusiastic in throwing out the baby in this case.
Now to turn cloudmark back on and see if that kills anything else.
Rgds
Denis McMahon
Pedt
5 Oct 2010, Denis McMahon <denis.m....@googlemail.com> wibbled
>On 04/10/10 20:30, Denis McMahon wrote:
>
>follow up to myself, bad form etc, I know
>
>However, I think I have solved the problem, it wasn't cloudmark.
>
>The fasthosts hosting package user...@host.domain that was being used
>for return-path and envelope-from in the postfix setup on the webserver
>was resolving to a class a private address (10.x.x.x)
>
>I suspect that demon was rejecting the message before it ever got to
>cloudmark on the basis that the return-path / envelope from was invalid
>because undeliverable / no mx entry.
More likely undeliverable Sender: at a guess.
I chucked one to postmaster@hostname to check and it barfed on the
Sender: Pe...@user-unknown.mx2.org.uk as it resolves to 127.0.0.1 and is
in DNS.
550-Unrouteable address
550-...@user-unknown.mx2.org.uk is a non-existent sender domain
--
Pedt
David Gibson
Oct 2010 Denis McMahon <denis.m....@googlemail.com> writes
>Having modified my php to use " -f user...@host.domain " as the fifth
>parameter on the call to the php mail() function, which appears to be
>setting the return-path acceptably, the mails are now getting through.
I was just about to suggest that :-)
I have had similar problems, caused by the above. See
http://uk3.php.net/manual/en/function.mail.php#92528
Another obscure problem to do with mail forwarding ...
http://uk3.php.net/manual/en/function.mail.php#92527
--
David Gibson
Spam-cloaked message: The Reply-to: address *is* valid.