SpamBlocker-Powered exim.conf, Version 4

Also, started to get lots of :
2012-07-27 16:57:14 Received from <> R=1Sumuc-0006xA-S5 U=mail P=local S=1048 T="Autoreply: \"FW: Test message\""
2012-07-27 16:57:14 routing failed for [email protected] F=<>: Unrouteable address
*** Frozen (delivery error message)
Click to expand...
What is that all about :(

Might as well revert back to v2 config.

Edit: Ok, I know why: "The unknown account has just finished sending 1000 emails." is blocking but ever since I changed to 4.1, I get these messages.....

Edit:
Received from <>
Click to expand...
I'm not sure why Vocation replies are not setting a sender address, therefore adding to the unknown usage? Am I right there's no sender address?
 
Last edited:
Maybe you should ask Jeff Lasman (nobaloney) that wrote spamblocker file and can for sure give a better reply.

Honestly i dont know where you can edit the file to fit your needs.

Sorry

Regards
 
I just don't know why the unknown user is being used a lot - there's no hacked accounts (even though most are set to a 260 day limit), nor any dodgy phpmail forms being used (wouldn't even register with exim would it, if phpmail() was used?).

But yeah, lets hope Jeff see's this..... In the meantime, I've increased the limit_unknown file, so that mail can get to its destination at least within 24hours....

Shame though, it's doing such a good job in detecting and rejecting pesky spam. lol

Also, the reason the "HELO" block was happening still: as the client using Outlook 2003, it seems it wasn't saving any preferences. I think we have sorted this part out at least.
 
I see it. I don't know what to do about it because I'm still unsure of the exact issue. Exim is designed to work according to the RFCs and my spamblocker file as closely to the RFCs as possible. I recommend NOT opening up your server to be an open relay on port 25, for obvious reasons.

And I believe (am I wrong?) that exim isn't responsible if your email isn't being sent as the correct user.

I recommend using latest version of exim.pl, and when I rebuild exim.conf I only test against latest version of exim.pl.

If I've missed something, or if you have a specific question within the realm of SpamBlocker exim.conf version 4.1, ask and I'll do my best to respond.

Jeff
 
Which is the latest exim.pl? Version 10? If so, already got that

Even with increasing limit_unknown, still get warnings.

Maybe I'm not explaining properly. The issue was that a client was getting this "HELO" block even if he was using port 587. Turns out that it was their fault as Outlook never saved any preferences, hence still trying to connect to port 25.
This part has all been sorted. Now it's this unknown user issue.

And I believe (am I wrong?) that exim isn't responsible if your email isn't being sent as the correct user.
Click to expand...

Here's a snippet of my last warning today:
After some processing of the /etc/virtual/usage/unknown.bytes file, it was found that the highest sender was [email protected], at 3 emails.
Click to expand...
Not sure what that means, unless DA gets the highest sender? I also get some with blank as the sender:
After some processing of the /etc/virtual/usage/unknown.bytes file, it was found that the highest sender was , at nn emails.
Click to expand...
All I can think is this unknown user is being used for bounces? (If it was an actual account, it'll say the user and their limit in the admin's warning of the limit hit email that's sent). As when they get frozen, the Sender column in the Mail Queue in DA is blank (well, <>). But 2,500 (was set to 1,000) bounces or unknown senders is a hell of a lot?

I admit that I'm no expert with exim's logs etc, so I can't really debug as I'm do not know what to look for.
 
To add, and as I'm using RBLs now.

My DNS servers (at data centre) are dodgy, so I opted to us Google & OpenDNS. However, I was advised not to as:
You end up with invalid responses from SBLs like Spamhaus because the lookups are DNS based (and Google will reply with NXDOMAIN, whilst OpenDNS will reply with a default IP address for their search page). So on a mail server, install your own internal DNS resolver or use DNSMASQ.
Click to expand...
This true?

I tried 127.0.0.1 and some RBL couldn't be found (using nslookup), whereas using Google or OpenDNS could :confused:
# nslookup zen.spamhaus.org
Server: 127.0.0.1
Address: 127.0.0.1#53
Non-authoritative answer:
*** Can't find zen.spamhaus.org: No answer
Click to expand...
~# nslookup zen.spamhaus.org
Server: 208.67.222.222
Address: 208.67.222.222#53

Non-authoritative answer:
Name: zen.spamhaus.org
Address: 67.215.77.132
Click to expand...
Are there any drawbacks from using local 127.0.0.1 for look ups?
 
Peter Laws said:
Are there any drawbacks from using local 127.0.0.1 for look ups?
Click to expand...
The main reason is that you shouldn't have your local DNS server set to do recursive lookups; authoritative nameservers should be just that, and only that, to avoid DNS cache poisoning issues.

I've never had a problem with using Google's nameservers, but I have no idea what you mean by for their search page so maybe I'm missing something in your post.

Jeff
 
#EDIT#40:
deny message = Forged Paypal Mail, not sent from PayPal.
senders = *@paypal.com
condition = ${if match {$sender_host_name}{\Npaypal.com$\N}{no}{yes}}
Click to expand...
I'm noticing that spoof emails are getting through. Is this 100% working does it work intermittently?
From - Thu Aug 16 11:19:37 2012
X-Account-Key: account13
X-UIDL: 000000384dc98c70
X-Mozilla-Status: 0000
X-Mozilla-Status2: 00000000
X-Mozilla-Keys:
Return-path: <[email protected]>
Envelope-to: [email protected]
Delivery-date: Thu, 16 Aug 2012 10:49:54 +0100
Received: from mail by server3.laws-hosting.co.uk with spam-scanned (Exim 4.76)
(envelope-from <[email protected]>)
id 1T1wiA-0007Cu-H2
for [email protected]; Thu, 16 Aug 2012 10:49:54 +0100
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
server3.laws-hosting.co.uk
X-Spam-Level:
X-Spam-Status: No, score=0.3 required=4.0 tests=BAYES_00,HTML_IMAGE_RATIO_06,
HTML_MESSAGE,MIME_HEADER_CTYPE_ONLY,MIME_HTML_ONLY,RDNS_NONE autolearn=no
version=3.3.1
Received: from [193.137.75.138] (helo=gvelho.ulusofona.pt)
by server3.laws-hosting.co.uk with esmtp (Exim 4.76)
(envelope-from <[email protected]>)
id 1T1wiA-0007Co-9I
for [email protected]; Thu, 16 Aug 2012 10:49:54 +0100
Received: by gvelho.ulusofona.pt (Postfix, from userid 30)
id 0B6FCD66F; Thu, 16 Aug 2012 10:30:16 +0100 (WEST)
To: [email protected]
Subject: Limited Account !
X-PHP-Originating-Script: 30:slave1.php
From: PayPal <[email protected]>
Content-Type: text/html
Message-Id: <[email protected]>
Date: Thu, 16 Aug 2012 10:30:16 +0100 (WEST)
X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner
Click to expand...
 
It should work. Is the mailbox address on this server, or is it being forwarded elsewhere?

Is the email being whitelisted or accepted above the #Edit#40 stanza?

I've never seen these forgeries get through.

Jeff
 
Just a question about this.

To me seems to be normal cause the rule is: senders = *@paypal.com
And the email source yoou posted have: From: PayPal <[email protected]>

So, there is no match on the domain and the rule should not be called, am i wrong?

Regards
 
SeLLeRoNe said:
Just a question about this.

To me seems to be normal cause the rule is: senders = *@paypal.com
And the email source yoou posted have: From: PayPal <[email protected]>
Click to expand...
AFAIK, it checks the hostname:
condition = ${if match {$sender_host_name}{\Npaypal.com$\N}{no}{yes}}
Click to expand...
so regardless whether the Sender is @paypal.xxx, it still would be blocked?

Wrong/Fake:
Received: from [193.137.75.138] (helo=gvelho.ulusofona.pt)
by server3.laws-hosting.co.uk with esmtp (Exim 4.76)
(envelope-from <[email protected]>)
Click to expand...
Right/Genuine:
Received: from mx3.slc.paypal.com ([173.0.84.228] helo=mx2.slc.paypal.com)
by server3.laws-hosting.co.uk with esmtp (Exim 4.76)
(envelope-from <[email protected]>)
Click to expand...
 
Last edited:
Peter Laws said:
AFAIK, it checks the hostname:

so regardless whether the Sender is @paypal.xxx, it still would be blocked?
Click to expand...
I see what SeLLeRoNe means.

My code checks the sender against the hostname, and if the sender is @paypal.co.uk, falsifications will get through because the hostname won't even be checked.

So to fix it I need to know which domains PayPal sends from.

Please let me know by replying here of all the known senders from which you get known good PayPal emil, and I'll be happy to make the code more robust.

Thanks for bringing this to my attention SeLLeRoNe.

Jeff
 
It's always paypal.com (host) for me, but it could be paypal.co.uk as the sender/from (but still paypal.com in the return-path, etc headers), if someone sends money then their email is useed as the sender/from.

As the return-path is always paypal.com (afaics), wouldn't it be better to check that instead? - I know it can be forged, but web forms will return differently, unless they're sophisticated.
 
I believe the Sender is the same as the Return Path. Care to do some testing?

Jeff
 
when payment is received:
Return-path: <[email protected]>
From: <[email protected]> (or it could be the email of the buyer)
Sender: [email protected] (not always included)
Click to expand...

from T&C/etc updates:
Return-path: <JQ9OHYV-XRRKW-IYBAZS-ACJXEI-PR19BQ-H-M2-20120807-e3d6897b79527bb@emea.e.paypal.com>
Click to expand...
no Sender

for any account updates (change password, withdraw, suspicious activity, etc):
Return-path: <[email protected]>
From: <[email protected]>
Click to expand...
no Sender

replies from contact us form:
Return-path: <[email protected]>
From: <[email protected]>
Click to expand...
no Sender

Not sure this helps.
 
Last edited:
Peter Laws said:
Not sure this helps.
Click to expand...
It helps, but I don't want to make changes each time someone discovers another return address for PayPal. So what I need is a list of domains for differrent countries that PayPal uses for outgoing email. So let's see if more people respond.

Jeff
 
I received a call today from a hosting client who said that he wasn't receiving email from one particular sender ([email protected]). I dug into the mainlog file and found the following (I've obscured the IP address for the receiver and domain names with "sender.com" and "receiver.com").

Code: 
2012-08-23 11:50:45 1T4Zfv-0001OS-Tp <= [email protected] H=smtpauth20.prod.mesa1.secureserver.net [64.202.165.36] P=smtp S=15773569 id=0ee501cd8146$b91928a0$2b4b79e0$@com T="FW: Waverly Quarterly" from <jmullen@sender> for [email protected]
2012-08-23 11:50:46 1T4Zfv-0001OS-Tp => bob.smith <[email protected]> F=<[email protected]> R=virtual_user T=virtual_localdelivery S=15773687
2012-08-23 12:01:09 H=(pps.com) [7.8.5.33] F=<> rejected RCPT <[email protected]>: We didn't send the message

The sender never received a failure notification. For now I've added the sender's domain name to the whitelist_domains file and seem to have gotten around the problem temporarily.

The obscured IP of 7.8.5.33 is the IP address of my client's Exchange 2003 server that retrieves email from DA via POP3 Connector.

Can anyone decipher this and help me understand what might be happening?
 
Peter Laws said:
It's always paypal.com (host) for me, but it could be paypal.co.uk as the sender/from (but still paypal.com in the return-path, etc headers), if someone sends money then their email is useed as the sender/from.

As the return-path is always paypal.com (afaics), wouldn't it be better to check that instead? - I know it can be forged, but web forms will return differently, unless they're sophisticated.
Click to expand...

Aren't all notifications from PayPal coming from [email protected]? Anyway here is at least one email on host @paypal.com mentioned (it is [email protected]):

https://www.paypal.com/webapps/helpcenter/article/?articleID=94034&topicID=11500023&m=TTQ
 
You must log in or register to reply here.
Back
Top