On 03/12/2016 13:57, Matus UHLAR - fantomas wrote:
On 25/11/2016 11:22, Matus UHLAR - fantomas wrote:
This says that the mail was received from webpage on your server,
and the
local mailer "nullmailer" seems have delivered it directly to you.
in fact, you don't know anything about this mail - it was apparently
received via HTTP, but the SendMail.class.php running under uid
7637323 did
not provide even remote IP address.
apparently SA can't parse nullmailer headers - apparently because
nullmailer
provides no useful headers.
in this case it's really hard to detect anything, since all
information
about mail is lost in PHP.
Maybe PHP could at least provide client's IP (maybe all in
x-forwarded-for
path) and that could help us.
On 28/11/2016 22:10, geoff.sa_users_161...@alphaworks.co.uk wrote:
Apologies for the delay but my hosting support looked into this on
Friday and had the following to say:
We have checked this for you and indeed these spam messages were
sent by a PHP script outside of your system.
Note this mail has not been sent in behalf of your domain, maybe
from an exploited domain outside of your system.
2016-11-25T11:15:25.755261+00:00 server postfix/smtpd[6946]:
B85B52E0097: client=unknown[120.188.64.47]
2016-11-25T11:15:26.510335+00:00 server postfix/cleanup[2877]:
B85B52E0097:
message-id=<7009914603.543683.47189.sendm...@alphaworks.co.uk>
2016-11-25T11:15:26.565616+00:00 server postfix/qmgr[1914]:
B85B52E0097: from=<mendez.derr...@cncvacation.com>, size=5340,
nrcpt=1 (queue active)
2016-11-25T11:15:30.892826+00:00 server postfix/pipe[8646]:
B85B52E0097: to=<__REMOVED__>, orig_to=<__REMOVED__>,
relay=plesk_virtual, delay=5.2, delays=0.91/0/0/4.3, dsn=2.0.0,
status=sent (delivered via plesk_virtual service)
Also, we checked the SPF record of the sender which is very weak
(enclosed with ?all instead of stricter -all ), and to reject such
mails you can turn on SPF spam protection at > Tools &Settings >
Mail Server Settings > check Switch on SPF spam protection and at
the drop down menu select Reject mail when SPF resolves to neutral.
So it didn't originate within my system, which is a relief...
Does this go any way to explain why we're seeing UNPARSEABLE_RELAY?
Does setting my VPS's "SPF spam protection" to "Reject mail when SPF
resolves to neutral" sound a sensible course of action?
On 03.12.16 13:25, geoff.sa_users_161...@alphaworks.co.uk wrote:
Sorry to respond to my own message but I wondered if anyone had any
thoughts on this? Is the SPF solution appropriate (i.e. reasonably
low risk of false positives) or is there something I could do with
SpamAssassin to better deal with these?
Only what was already said:
You see UNPARSEABLE_RELAY, because SA is unable to parse nullmailer's
Received: headers. There's nothing to parse at all - the mail originated
locally, posted via PHP script. PHP did not even provide information
about IP address the mail was sent from, which is something that could
change (and could give you benefit of looking up that IP in blacklists).
The only thing SA can do about this is to understand nullmailer's
Received: and
drop UNPARSEABLE_RELAY, but that would change nothing - adding
Received: via
PHP could something...
Ah, I think I've been making an invalid assumption here...
Because every one of these messages had a UNPARSEABLE_RELAY and nothing
else, I thought that this issue was stopping any other tests being
applied. What I now realise (I think!) is that they're failing no other
tests because the majority of tests relate to the path the message has
taken to my mail server and without information on that, all of those
tests can't be applied. Is my revised understanding correct?
Thanks for your patience!
