Re: Spam with attachments and UNPARSEABLE_RELAY

[geoff . sa_users_161124]

On 05/12/2016 23:06, John Hardin wrote:

On Mon, 5 Dec 2016, geoff.sa_users_161...@alphaworks.co.uk wrote:

Yeah, that's pretty much a requirement. You need a folder of ham (both 
good ham and FPs) and a folder of spam (both spam and FNs) and you run 
sa-learn to scan them and load the tokens into the Bayes database.


Not having root access may be a big hurdle - how do you manage the 
system without root access? Who *does* have root access?


If you're managing this via a control panel of some sort, poke around 
and see what facilities it gives you to control training. If that's 
the case, though, we may not be able to help you much because anything 
like that is a third-party tool and none of the SA list denizens may 
be familiar with it. You'll probably have to go to your managed 
hosting provider for assistance.




The hosting company has root access and their support keep the server 
updated etc. I think they installed SpamAssassin on my request so I'll 
have a word with them about the training. To be honest, apart from this 
UNPARSEABLE_RELAY issue, SpamAssassin is behaving near flawlessly...


Many thanks,
Geoff

Re: Spam with attachments and UNPARSEABLE_RELAY

[John Hardin]

On Mon, 5 Dec 2016, geoff.sa_users_161...@alphaworks.co.uk wrote:


On 05/12/2016 22:38, John Hardin wrote:

 On Mon, 5 Dec 2016, geoff.sa_users_161...@alphaworks.co.uk wrote:

>  OK, blindly following your suggestion yielded the following; does it 
>  tell you anything?
> 
>  Dec  5 22:20:11.805 [30090] dbg: bayes: not available for scanning, only 
>  0 spam(s) in bayes DB < 200


 0 spams. You need to train it with at least 200 ham and 200 spam messages
 before it can start analyzing messages.

 Are you training at all?

 Are you training the right Bayes database?




Does the 'blindly' give you a clue as to my answers? ;)


Heh.


I'm afraid the answer to the first question is no...


Then no Bayes hits isn't surprising.

Thinking about it, I don't have access to my emails on the command line (I 
don't have root access as it's a maintained VPS) so I'm not sure I'd be able 
to if training requires me pointing SA at folders of mail?


Yeah, that's pretty much a requirement. You need a folder of ham (both 
good ham and FPs) and a folder of spam (both spam and FNs) and you run 
sa-learn to scan them and load the tokens into the Bayes database.


Not having root access may be a big hurdle - how do you manage the system 
without root access? Who *does* have root access?


If you're managing this via a control panel of some sort, poke around and 
see what facilities it gives you to control training. If that's the case, 
though, we may not be able to help you much because anything like that is 
a third-party tool and none of the SA list denizens may be familiar with 
it. You'll probably have to go to your managed hosting provider for 
assistance.


--
 John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
 jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
 key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
---
  You do not examine legislation in the light of the benefits it
  will convey if properly administered, but in the light of the
  wrongs it would do and the harms it would cause if improperly
  administered.  -- Lyndon B. Johnson
---
 10 days until Bill of Rights day

Re: Spam with attachments and UNPARSEABLE_RELAY

[geoff . sa_users_161124]

On 05/12/2016 22:38, John Hardin wrote:

On Mon, 5 Dec 2016, geoff.sa_users_161...@alphaworks.co.uk wrote:

OK, blindly following your suggestion yielded the following; does it 
tell you anything?


Dec  5 22:20:11.805 [30090] dbg: bayes: not available for scanning, 
only 0 spam(s) in bayes DB < 200


0 spams. You need to train it with at least 200 ham and 200 spam 
messages before it can start analyzing messages.


Are you training at all?

Are you training the right Bayes database?




Does the 'blindly' give you a clue as to my answers? ;)
I'm afraid the answer to the first question is no...
Thinking about it, I don't have access to my emails on the command line 
(I don't have root access as it's a maintained VPS) so I'm not sure I'd 
be able to if training requires me pointing SA at folders of mail?


Many thanks,
Geoff

Re: Spam with attachments and UNPARSEABLE_RELAY

[John Hardin]

On Mon, 5 Dec 2016, geoff.sa_users_161...@alphaworks.co.uk wrote:

OK, blindly following your suggestion yielded the following; does it tell you 
anything?


Dec  5 22:20:11.805 [30090] dbg: bayes: not available for scanning, only 0 
spam(s) in bayes DB < 200


0 spams. You need to train it with at least 200 ham and 200 spam messages 
before it can start analyzing messages.


Are you training at all?

Are you training the right Bayes database?


--
 John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
 jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
 key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
---
  You do not examine legislation in the light of the benefits it
  will convey if properly administered, but in the light of the
  wrongs it would do and the harms it would cause if improperly
  administered.  -- Lyndon B. Johnson
---
 10 days until Bill of Rights day

Re: Spam with attachments and UNPARSEABLE_RELAY

[geoff . sa_users_161124]

On 24/11/2016 13:09, RW wrote:

On Thu, 24 Nov 2016 11:33:19 +0100
Axb wrote:


On 11/24/2016 11:23 AM, Geoff Soper wrote:

For a few weeks I've been suffering spam messages with attachments
getting through with a suspicious score of 0.0. Upon inspection,
they all had the following lines in the header:

...
X-Spam-Status: No, score=0.0 required=3.0 tests=UNPARSEABLE_RELAY
 autolearn=unavailable version=3.3.2

Do you normally have a BAYES_* result in  X-Spam-Status? I think that
autolearn=unavailable implies that Bayes is configured to be on.

Try running one of these through spamassassin -D bayes

If you haven't already done it, set "bayes_auto_expire 0" and instead
run "sa-learn --force-expire" from cron (as the correct user).


OK, blindly following your suggestion yielded the following; does it 
tell you anything?


Thanks!

-bash-3.2$ spamassassin -D bayes "Important Information.eml"
Dec  5 22:20:11.796 [30090] dbg: bayes: learner_new 
self=Mail::SpamAssassin::Plugin::Bayes=HASH(0xaa859f0), 
bayes_store_module=Mail::SpamAssassin::BayesStore::DBM
Dec  5 22:20:11.803 [30090] dbg: bayes: learner_new: got 
store=Mail::SpamAssassin::BayesStore::DBM=HASH(0xacfea30)
Dec  5 22:20:11.804 [30090] dbg: bayes: tie-ing to DB file R/O 
/var/www/vhosts/alphaworks.co.uk/.spamassassin/bayes_toks
Dec  5 22:20:11.804 [30090] dbg: bayes: tie-ing to DB file R/O 
/var/www/vhosts/alphaworks.co.uk/.spamassassin/bayes_seen

Dec  5 22:20:11.804 [30090] dbg: bayes: found bayes db version 3
Dec  5 22:20:11.804 [30090] dbg: bayes: DB journal sync: last sync: 0
Dec  5 22:20:11.805 [30090] dbg: bayes: not available for scanning, only 
0 spam(s) in bayes DB < 200

Dec  5 22:20:11.805 [30090] dbg: bayes: untie-ing
Dec  5 22:20:11.807 [30090] dbg: bayes: tie-ing to DB file R/O 
/var/www/vhosts/alphaworks.co.uk/.spamassassin/bayes_toks
Dec  5 22:20:11.807 [30090] dbg: bayes: tie-ing to DB file R/O 
/var/www/vhosts/alphaworks.co.uk/.spamassassin/bayes_seen

Dec  5 22:20:11.808 [30090] dbg: bayes: found bayes db version 3
Dec  5 22:20:11.808 [30090] dbg: bayes: DB journal sync: last sync: 0
Dec  5 22:20:11.808 [30090] dbg: bayes: not available for scanning, only 
0 spam(s) in bayes DB < 200

Dec  5 22:20:11.808 [30090] dbg: bayes: untie-ing
Dec  5 22:20:12.710 [30090] dbg: bayes: tie-ing to DB file R/W 
/var/www/vhosts/alphaworks.co.uk/.spamassassin/bayes_toks
Dec  5 22:20:12.710 [30090] dbg: bayes: tie-ing to DB file R/W 
/var/www/vhosts/alphaworks.co.uk/.spamassassin/bayes_seen

Dec  5 22:20:12.711 [30090] dbg: bayes: found bayes db version 3
Dec  5 22:20:12.711 [30090] dbg: bayes: 
38b0ea13de18c1493d348447e5778b92e3bb542b@sa_generated already learnt 
correctly, not learning twice

Dec  5 22:20:12.711 [30090] dbg: bayes: untie-ing
Dec  5 22:20:12.711 [30090] dbg: bayes: files locked, now unlocking lock
Return-Path: 
X-Spam-Relays-External:
X-Spam-Relays-Untrusted:
X-Spam-Flag: NO
X-Spam-Status: No, Score=0.0
X-Spam-Report:
*  0.0 UNPARSEABLE_RELAY Informational: message has unparseable 
relay lines

X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on
server.alphaworks.co.uk
X-Spam-Score: 0.0
X-Original-To: @alphaworks.co.uk
Delivered-To: @alphaworks.co.uk
X-No-Auth: unauthenticated sender
Received: (nullmailer pid 84240 invoked by uid 0334909);
Fri, 25 Nov 2016 18:15:24 +0700
X-No-Auth: unauthenticated sender
Received: from internal (unknown [x.x.x.x])
Received: (nullmailer pid 84240 invoked by uid 0334909);
Fri, 25 Nov 2016 18:15:24 +0700
To: <@alphaworks.co.uk>
Subject: *** VIRUS ***Important Information
X-PHP-Originating-Script: 0334909:SendMail.class.php
From: "Derrick Mendez" 
Date: Fri, 25 Nov 2016 18:15:24 +0700
MIME-Version: 1.0
Content-Type: multipart/related; boundary="e161521dd66255192e4d83eb2e8a112f"
Message-Id: <7009914603.543683.47189.sendm...@alphaworks.co.uk>
X-Procmail-Alphaworks-Geoff: 27/01/2014
X-Procmail-HeaderInclude: 27/01/2014
X-Procmail-Alphaworks-Whitelist: 27/01/2014
X-Procmail-DomainInclude: 27/01/2014
X-Procmail-Alphaworks-Blacklist: 27/01/2014
X-Procmail-BounceInclude: 27/01/2014
X-Procmail-DotInclude: 25/12/2009
X-Procmail-SpamAssassinInclude: 25/12/2009
X-Procmail-FooterInclude: 25/12/2009
X-Antivirus: avast! (VPS 161124-7, 24/11/2016), Inbound message
X-Antivirus-Status: Infected
X-Attachment: payment_.zip#2742364094|>HQ9eug679i3l.js Virus: 
JS:LockyDownloader [Trj] Deleted


--e161521dd66255192e4d83eb2e8a112f
Content-type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Dear , your payment was not processed due to the =
problem with credentials.
Payment details are in the attached document.

Please check it out as soon as possible.
--e161521dd66255192e4d83eb2e8a112f--

-bash-3.2$

Re: Spam with attachments and UNPARSEABLE_RELAY

[geoff . sa_users_161124]

On 03/12/2016 19:23, RW wrote:

On Sat, 3 Dec 2016 14:18:38 +
geoff.sa_users_161...@alphaworks.co.uk wrote:



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?

Sort of, but it's a more like a significant minority. And if they
turned-off network tests it's much less significant. The received
headers that were there are of no interest anyway.  It's just as
worrying that there was no Bayes result.

Some spam does hit few tests, do you have any that hits lots?

The spam that customer services commented on doesn't appear to be the
same one that that you posted. If the quoted one is external then there
must be at least one missing received header. Possibly Plesk is doing
something unusual, "(delivered via plesk_virtual service)" looks a
bit suspicious.


For what it's worth, this is the example I sent to support...

I'll look at Bayes now.

Thanks!
--- Begin Message ---
Dear , your payment was not processed due to the problem with 
credentials.
Payment details are in the attached document.

Please check it out as soon as possible.--- End Message ---

Re: Spam with attachments and UNPARSEABLE_RELAY

[RW]

On Sat, 3 Dec 2016 14:18:38 +
geoff.sa_users_161...@alphaworks.co.uk wrote:


> 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?

Sort of, but it's a more like a significant minority. And if they
turned-off network tests it's much less significant. The received
headers that were there are of no interest anyway.  It's just as
worrying that there was no Bayes result. 

Some spam does hit few tests, do you have any that hits lots?

The spam that customer services commented on doesn't appear to be the
same one that that you posted. If the quoted one is external then there
must be at least one missing received header. Possibly Plesk is doing
something unusual, "(delivered via plesk_virtual service)" looks a
bit suspicious.  

Re: Spam with attachments and UNPARSEABLE_RELAY

[geoff . sa_users_161124]

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=, 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  >
   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!

Re: Spam with attachments and UNPARSEABLE_RELAY

[Matus UHLAR - fantomas]

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=, 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  >
   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...

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Linux - It's now safe to turn on your computer.
Linux - Teraz mozete pocitac bez obav zapnut.

Re: Spam with attachments and UNPARSEABLE_RELAY

[geoff . sa_users_161124]

On 28/11/2016 22:10, geoff.sa_users_161...@alphaworks.co.uk wrote:

On 25/11/2016 11:22, Matus UHLAR - fantomas wrote:

On 24.11.16 10:23, Geoff Soper wrote:

Subject: Spam with attachments and UNPARSEABLE_RELAY

For a few weeks I've been suffering spam messages with attachments 
getting through with a suspicious score of 0.0. Upon inspection, 
they all had the following lines in the header:


On 25.11.16 10:18, geoff.sa_users_161...@alphaworks.co.uk wrote:
1. See attached example. I've removed the username and replaced it 
with .
2. Other mail is getting correctly identified as spam so that's 
something...



Return-Path: <gardner.esmera...@microauto.com>
X-Spam-Report:
*  0.0 UNPARSEABLE_RELAY Informational: message has unparseable 
relay lines



Received: (nullmailer pid 36796 invoked by uid 7637323);
Fri, 25 Nov 2016 12:23:11 +0500
X-No-Auth: unauthenticated sender
Received: from internal (unknown [x.x.x.x])
Received: (nullmailer pid 36796 invoked by uid 7637323);
Fri, 25 Nov 2016 12:23:11 +0500
X-PHP-Originating-Script: 7637323:SendMail.class.php


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.


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  >
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?


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?


Many thanks

Re: Spam with attachments and UNPARSEABLE_RELAY

[geoff . sa_users_161124]

On 25/11/2016 11:22, Matus UHLAR - fantomas wrote:

On 24.11.16 10:23, Geoff Soper wrote:

Subject: Spam with attachments and UNPARSEABLE_RELAY

For a few weeks I've been suffering spam messages with attachments 
getting through with a suspicious score of 0.0. Upon inspection, 
they all had the following lines in the header:


On 25.11.16 10:18, geoff.sa_users_161...@alphaworks.co.uk wrote:
1. See attached example. I've removed the username and replaced it 
with .
2. Other mail is getting correctly identified as spam so that's 
something...



Return-Path: <gardner.esmera...@microauto.com>
X-Spam-Report:
*  0.0 UNPARSEABLE_RELAY Informational: message has unparseable 
relay lines



Received: (nullmailer pid 36796 invoked by uid 7637323);
Fri, 25 Nov 2016 12:23:11 +0500
X-No-Auth: unauthenticated sender
Received: from internal (unknown [x.x.x.x])
Received: (nullmailer pid 36796 invoked by uid 7637323);
Fri, 25 Nov 2016 12:23:11 +0500
X-PHP-Originating-Script: 7637323:SendMail.class.php


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.


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  >
   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?


Many thanks,
Geoff

Re: Spam with attachments and UNPARSEABLE_RELAY

[Ian Zimmerman]

On 2016-11-25 13:57, Bill Cole wrote:

> It LOOKS like that is being generated by a PHP script on the host that's 
> delivering it, which appears to be running some atrocious mail handler 
> calling itself 'nullmailer' that doesn't do Received headers in any 
> useful way.

FWIW nullmailer is a respected minimalist MTA:

 [1+0]~$ apt-cache show nullmailer
Package: nullmailer
Version: 1:1.13-1+deb8u1
Installed-Size: 2360
Maintainer: Nick Leverton 
Architecture: amd64
Replaces: mail-transport-agent
Provides: mail-transport-agent
Depends: lsb-base, debconf (>= 0.5) | debconf-2.0, libc6 (>= 2.15),
 libgnutls-deb0-28 (>= 3.3.0), libstdc++6 (>= 4.1.1)
Recommends: rsyslog | system-log-daemon
Conflicts: mail-transport-agent
Description-en: simple relay-only mail transport agent
 Nullmailer is a replacement MTA for hosts, which relay to a fixed set of
 smart relays. It is designed to be simple to configure and especially
 useful on slave machines and in chroots.
Description-md5: cf5bb13c21a01ffa34dc0048e9689c33
Homepage: http://untroubled.org/nullmailer/
Tag: interface::daemon, mail::transport-agent, network::server,
 protocol::smtp, role::program, works-with::mail
Section: mail
Priority: extra
Filename: pool/main/n/nullmailer/nullmailer_1.13-1+deb8u1_amd64.deb
Size: 92642


-- 
Please *no* private Cc: on mailing lists and newsgroups
Personal signed mail: please _encrypt_ and sign
Don't clear-text sign: http://cr.yp.to/smtp/8bitmime.html

Re: Spam with attachments and UNPARSEABLE_RELAY

[Bill Cole]

On 25 Nov 2016, at 5:28, geoff.sa_users_161...@alphaworks.co.uk wrote:


On 25/11/2016 10:26, Paul Stead wrote:

On 25/11/16 10:18, geoff.sa_users_161...@alphaworks.co.uk wrote:

X-Antivirus: avast! (VPS 161124-7, 24/11/2016), Inbound message
X-Antivirus-Status: Infected
X-Attachment: INVOICE_.zip#1783656308|>HQ2s9y6f.js   Virus: 
JS:LockyDownloader [Trj] Deleted


Your AV correctly identified the bad attachment - generally these 
don't

even get as far as SA in my setup

This all depends on the glue used and ordering within your MTA and 
how

it reacts to malware attachments



I don't have a lot of control over my setup as it's a hosted VPS. The 
AV is locally on my PC so comes late in the process...



That might explain why there's no valid Received header in the whole 
message...


It LOOKS like that is being generated by a PHP script on the host that's 
delivering it, which appears to be running some atrocious mail handler 
calling itself 'nullmailer' that doesn't do Received headers in any 
useful way. It might help to know what the 'x.x.x.x' was, but I suspect 
not much. The mess of headers MAY be secondary to your AV mangling the 
message and reconstructing it without the original headers.

Re: Spam with attachments and UNPARSEABLE_RELAY

[geoff . sa_users_161124]

On 25/11/2016 11:22, Matus UHLAR - fantomas wrote:

On 24.11.16 10:23, Geoff Soper wrote:

Subject: Spam with attachments and UNPARSEABLE_RELAY

For a few weeks I've been suffering spam messages with attachments 
getting through with a suspicious score of 0.0. Upon inspection, 
they all had the following lines in the header:


On 25.11.16 10:18, geoff.sa_users_161...@alphaworks.co.uk wrote:
1. See attached example. I've removed the username and replaced it 
with .
2. Other mail is getting correctly identified as spam so that's 
something...



Return-Path: <gardner.esmera...@microauto.com>
X-Spam-Report:
*  0.0 UNPARSEABLE_RELAY Informational: message has unparseable 
relay lines



Received: (nullmailer pid 36796 invoked by uid 7637323);
Fri, 25 Nov 2016 12:23:11 +0500
X-No-Auth: unauthenticated sender
Received: from internal (unknown [x.x.x.x])
Received: (nullmailer pid 36796 invoked by uid 7637323);
Fri, 25 Nov 2016 12:23:11 +0500
X-PHP-Originating-Script: 7637323:SendMail.class.php


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.



Thanks for this analysis, this rings alarm bells. Can you be sure that 
this is definitely coming from a PHP on my server? I'll start 
investigating on the assumption that it is.


Many thanks,
Geoff

Re: Spam with attachments and UNPARSEABLE_RELAY

[Matus UHLAR - fantomas]

On 24.11.16 10:23, Geoff Soper wrote:

Subject: Spam with attachments and UNPARSEABLE_RELAY

For a few weeks I've been suffering spam messages with 
attachments getting through with a suspicious score of 0.0. Upon 
inspection, they all had the following lines in the header:


On 25.11.16 10:18, geoff.sa_users_161...@alphaworks.co.uk wrote:
1. See attached example. I've removed the username and replaced it 
with .

2. Other mail is getting correctly identified as spam so that's something...



Return-Path: <gardner.esmera...@microauto.com>
X-Spam-Report:
*  0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay 
lines



Received: (nullmailer pid 36796 invoked by uid 7637323);
Fri, 25 Nov 2016 12:23:11 +0500
X-No-Auth: unauthenticated sender
Received: from internal (unknown [x.x.x.x])
Received: (nullmailer pid 36796 invoked by uid 7637323);
Fri, 25 Nov 2016 12:23:11 +0500
X-PHP-Originating-Script: 7637323:SendMail.class.php


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.

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Spam is for losers who can't get business any other way.

Re: Spam with attachments and UNPARSEABLE_RELAY

[geoff . sa_users_161124]

On 25/11/2016 10:26, Paul Stead wrote:

On 25/11/16 10:18, geoff.sa_users_161...@alphaworks.co.uk wrote:

X-Antivirus: avast! (VPS 161124-7, 24/11/2016), Inbound message
X-Antivirus-Status: Infected
X-Attachment: INVOICE_.zip#1783656308|>HQ2s9y6f.js   Virus: 
JS:LockyDownloader [Trj] Deleted


Your AV correctly identified the bad attachment - generally these don't
even get as far as SA in my setup

This all depends on the glue used and ordering within your MTA and how
it reacts to malware attachments



I don't have a lot of control over my setup as it's a hosted VPS. The AV 
is locally on my PC so comes late in the process...

Re: Spam with attachments and UNPARSEABLE_RELAY

[Paul Stead]

On 25/11/16 10:18, geoff.sa_users_161...@alphaworks.co.uk wrote:

X-Antivirus: avast! (VPS 161124-7, 24/11/2016), Inbound message
X-Antivirus-Status: Infected
X-Attachment: INVOICE_.zip#1783656308|>HQ2s9y6f.js   Virus: 
JS:LockyDownloader [Trj] Deleted


Your AV correctly identified the bad attachment - generally these don't
even get as far as SA in my setup

This all depends on the glue used and ordering within your MTA and how
it reacts to malware attachments

Paul
--
Paul Stead
Systems Engineer
Zen Internet

Re: Spam with attachments and UNPARSEABLE_RELAY

[geoff . sa_users_161124]

On 24/11/2016 13:15, Matus UHLAR - fantomas wrote:

On 24.11.16 10:23, Geoff Soper wrote:

Subject: Spam with attachments and UNPARSEABLE_RELAY

For a few weeks I've been suffering spam messages with attachments 
getting through with a suspicious score of 0.0. Upon inspection, they 
all had the following lines in the header:


X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on
server.alphaworks.co.uk
X-Spam-Level:
X-Spam-Status: No, score=0.0 required=3.0 tests=UNPARSEABLE_RELAY
autolearn=unavailable autolearn_force=no version=3.4.1
X-Spam-Score: 0.0


1. can you post headers from any such mail?

2. do other mails get catched or at least score different from 0.0 ?


Hi,
1. See attached example. I've removed the username and replaced it with 
.

2. Other mail is getting correctly identified as spam so that's something...

Many thanks,
Geoff
Return-Path: <gardner.esmera...@microauto.com>
X-Spam-Relays-External: 
X-Spam-Relays-Untrusted: 
X-Spam-Flag: NO
X-Spam-Status: No, Score=0.0
X-Spam-Report: 
*  0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay 
lines
X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on
server.alphaworks.co.uk
X-Spam-Score: 0.0
X-Original-To: @alphaworks.co.uk
Delivered-To: @alphaworks.co.uk
X-No-Auth: unauthenticated sender
Received: (nullmailer pid 36796 invoked by uid 7637323);
Fri, 25 Nov 2016 12:23:11 +0500
X-No-Auth: unauthenticated sender
Received: from internal (unknown [x.x.x.x])
Received: (nullmailer pid 36796 invoked by uid 7637323);
Fri, 25 Nov 2016 12:23:11 +0500
To: @alphaworks.co.uk>
Subject: *** VIRUS ***It Is Important
X-PHP-Originating-Script: 7637323:SendMail.class.php
From: "Esmeralda Gardner" <gardner.esmera...@microauto.com>
Date: Fri, 25 Nov 2016 12:23:11 +0500
MIME-Version: 1.0
Content-Type: multipart/related; boundary="4863c15906b03373f7d9d5b584584773"
Message-Id: <1124330643.045726.43998.sendm...@alphaworks.co.uk>
X-Procmail-Alphaworks-Geoff: 27/01/2014
X-Procmail-HeaderInclude: 27/01/2014
X-Procmail-Alphaworks-Whitelist: 27/01/2014
X-Procmail-DomainInclude: 27/01/2014
X-Procmail-Alphaworks-Blacklist: 27/01/2014
X-Procmail-BounceInclude: 27/01/2014
X-Procmail-DotInclude: 25/12/2009
X-Procmail-SpamAssassinInclude: 25/12/2009
X-Procmail-FooterInclude: 25/12/2009
X-Antivirus: avast! (VPS 161124-7, 24/11/2016), Inbound message
X-Antivirus-Status: Infected
X-Attachment: INVOICE_.zip#1783656308|>HQ2s9y6f.js Virus: 
JS:LockyDownloader [Trj] Deleted

--4863c15906b03373f7d9d5b584584773
Content-type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Dear , we received your invoice but couldn't pay, =
because your requisites were invalid.
Sending you the report of the problem - please open the attachment and =
check the data.
--4863c15906b03373f7d9d5b584584773--

Re: Spam with attachments and UNPARSEABLE_RELAY

[RW]

On Thu, 24 Nov 2016 13:09:28 +
RW wrote:


> UNPARSEABLE_RELAY is only a significant problem if it's on the edge of
> your internal or trusted network. These relays should be the
> first--force-expire entries in the above two headers - check that they
> are sensible.


Sorry, --force-expire got accidentally pasted into that paragraph.

Re: Spam with attachments and UNPARSEABLE_RELAY

[Matus UHLAR - fantomas]

On 24.11.16 10:23, Geoff Soper wrote:

Subject: Spam with attachments and UNPARSEABLE_RELAY

For a few weeks I've been suffering spam messages with attachments 
getting through with a suspicious score of 0.0. Upon inspection, they 
all had the following lines in the header:


X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on
server.alphaworks.co.uk
X-Spam-Level:
X-Spam-Status: No, score=0.0 required=3.0 tests=UNPARSEABLE_RELAY
autolearn=unavailable autolearn_force=no version=3.4.1
X-Spam-Score: 0.0


1. can you post headers from any such mail?

2. do other mails get catched or at least score different from 0.0 ?

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
My mind is like a steel trap - rusty and illegal in 37 states. 

Re: Spam with attachments and UNPARSEABLE_RELAY

[RW]

On Thu, 24 Nov 2016 11:33:19 +0100
Axb wrote:

> On 11/24/2016 11:23 AM, Geoff Soper wrote:
> > For a few weeks I've been suffering spam messages with attachments
> > getting through with a suspicious score of 0.0. Upon inspection,
> > they all had the following lines in the header:
> >
> > ...
> > X-Spam-Status: No, score=0.0 required=3.0 tests=UNPARSEABLE_RELAY
> > autolearn=unavailable version=3.3.2

Do you normally have a BAYES_* result in  X-Spam-Status? I think that 
autolearn=unavailable implies that Bayes is configured to be on.

Try running one of these through spamassassin -D bayes

If you haven't already done it, set "bayes_auto_expire 0" and instead
run "sa-learn --force-expire" from cron (as the correct user).


> Try this in your local.cf
> 
> clear_headers
> add_header all Relays-External _RELAYSEXTERNAL_
> add_header all Relays-Untrusted _RELAYSUNTRUSTED_

UNPARSEABLE_RELAY is only a significant problem if it's on the edge of
your internal or trusted network. These relays should be the
first--force-expire entries in the above two headers - check that they
are sensible.

Re: Spam with attachments and UNPARSEABLE_RELAY

[Axb]

On 11/24/2016 11:23 AM, Geoff Soper wrote:

For a few weeks I've been suffering spam messages with attachments
getting through with a suspicious score of 0.0. Upon inspection, they
all had the following lines in the header:

X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on
server.alphaworks.co.uk
X-Spam-Level:
X-Spam-Status: No, score=0.0 required=3.0 tests=UNPARSEABLE_RELAY
autolearn=unavailable version=3.3.2
X-Spam-Score: 0.0

As the first step in trying to resolve this, I updated to 3.4.1 which
results me in sometimes seeing (as expected):

X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on
server.alphaworks.co.uk
X-Spam-Level:
X-Spam-Status: No, score=0.0 required=3.0 tests=UNPARSEABLE_RELAY
autolearn=unavailable autolearn_force=no version=3.4.1
X-Spam-Score: 0.0

but also sometimes:

X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on
server.alphaworks.co.uk
X-Spam-Score: 0.0

i.e. missing X-Spam-Level: and X-Spam-Status:

Can anyone suggest what is going on here?


Try this in your local.cf

clear_headers
add_header all Relays-External _RELAYSEXTERNAL_
add_header all Relays-Untrusted _RELAYSUNTRUSTED_
add_header all Flag _YESNOCAPS_
add_header all Status _YESNO_, Score=_HITS_
add_header all Report _REPORT_
add_header all Checker-Version SpamAssassin _VERSION_ (_SUBVERSION_) on 
_HOSTNAME_


Also see "add_header" in SA docs for more options.

Spam with attachments and UNPARSEABLE_RELAY

[Geoff Soper]

For a few weeks I've been suffering spam messages with attachments 
getting through with a suspicious score of 0.0. Upon inspection, they 
all had the following lines in the header:


X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on
server.alphaworks.co.uk
X-Spam-Level:
X-Spam-Status: No, score=0.0 required=3.0 tests=UNPARSEABLE_RELAY
autolearn=unavailable version=3.3.2
X-Spam-Score: 0.0

As the first step in trying to resolve this, I updated to 3.4.1 which 
results me in sometimes seeing (as expected):


X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on
server.alphaworks.co.uk
X-Spam-Level:
X-Spam-Status: No, score=0.0 required=3.0 tests=UNPARSEABLE_RELAY
autolearn=unavailable autolearn_force=no version=3.4.1
X-Spam-Score: 0.0

but also sometimes:

X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on
server.alphaworks.co.uk
X-Spam-Score: 0.0

i.e. missing X-Spam-Level: and X-Spam-Status:

Can anyone suggest what is going on here?

Thanks,
Geoff