valid_from_domain and bounce mails missing from addresses

[stalks]

Plesk 8.6 running on Debian Etch, 2.6.18

Jul 9 14:13:28 enterprise magicspam-plesk[17515]: SPAM[valid_from_domain]: mua=0,ip=[195.241.xx.167:mail-in3.tiscali.nl],helo=<mail-in3.tiscali.nl>,from=<>,rcpt=<xx@xx.org.uk>

A mail was sent from our servers and immediately a bounce was returned, however the bounce mail was rejected due to no MAIL FROM.

The mail was sent from xx@xx.org.uk -> xx@tiscali.nl

The bounce sent from tiscali.nl to xx@xx.org.uk was rejected by MagicSpam, and a new bounce was sent to xx@xx.org.uk claiming the MAIL FROM was rejected which confused the end user.

How can I fix this?

An excerpt from qmail logs is at http://pastebin.com/m551068e

I may of got it wrong, its difficult to follow logs that overlap.

[magicspam]

Thank you for this detailed report! It certainly look like we may have a problem with our valid_from_domain rule.

We have notified our developers of this potential issues and they will be attempting to replicate it. Once they are able to replicate it, they will patch the problem for our next release.

Thanks again!

[magicspam]

Greetings,

We have been investigating this and so far have not been able to reproduce the issue as noted.

The rules themselves are designed to *not* trigger for cases where the MAIL FROM command is issued as:

MAIL FROM: <>

as part of best practices and RFC specifications. In this particular case as you have posted however, I am seeing some odd discrepancies.

In the qmail logs that you posted - are these from the server that is actually running MagicSpam? I'm finding it odd in particular that there is the line:

delivery 7221: failure: Connected_to_xx.xx.xx.xx_but_sender_was_rejected./...

Why is your server attempting to connect to a remote ip when delivering mail for xx.org.uk? Is that domain not hosted on your server? Additionally, why am I not finding any DNS records of any type for xx.org.uk?

If you could please clarify the conditions, that would be greatly helpful in tracking down the source of this issue.

-- MagicSpam Development Team --