Wizard IT Products

Hello

I receive a lot of this kind of emails like the one I'm attaching. I would like to know which best practice should I use, but at the same time not blocking emails from servers that are not spam.

Thanks in advance

Rafael

From - Wed Oct 07 15:54:11 2009
X-Account-Key: account2
X-UIDL: UID51954-1108421595
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
X-Mozilla-Keys:
DomainKey-Status: no signature
Received: (qmail 30191 invoked from network); 7 Oct 2009 14:55:23 -0700
Received: from 190.208.121.126 (HELO desktop.cpe.telmex.com.cl) (190.208.121.126)
by 209.216.241.225 with SMTP; 7 Oct 2009 14:55:22 -0700
Received-SPF: neutral (209.216.241.225: 190.208.121.126 is neither permitted nor denied by SPF record at royaddison.com)
Received: from 190.208.121.126 by mx1.biz.mail.yahoo.com; Wed, 7 Oct 2009 17:49:05 -0400
Message-ID: <01ca4776$76ba8a10$7e79d0be@linemenl5>
From: Viva_V1agra! <linemenl5@royaddison.com>
To: <info@adnsystems.com>
Subject: Reap the benefits of ordering your medications from Canada!
Date: Wed, 7 Oct 2009 17:49:05 -0400
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4927.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200

http://endtoward.com

In this particular case scenario, we note two rules that would block this particular email.

To start, the source server IP address of 190.208.121.126 does not have proper reverse DNS configured. The current PTR record assigned to that address is:

190.208.121.126

as opposed to an actual DNS name.. a big no no in terms of best practices for email servers. So.. with this in mind the rule 'check_dynamic_reverse_dns' should trigger on this particular server source.

Secondly, we note that the HELO argument that was issued does not resolve at all. There is a rule called 'resolve_helo_domain' which would trigger on this case scenario.

Please note however that enabling this rule will add some additional overhead (minimal ) to your antispam checks as it requires a DNS lookup for each email.

We hope this information helps!

Hello

I had those settings activated, but when activating some emails were rejected from customers, next you'll find an example (this email passed when disabling MagicSpam), the problem is that here a lot of people uses the 3G network from the Tigo carrier.

DomainKey-Status: no signature
Received: (qmail 23569 invoked by uid 48); 7 Oct 2009 10:57:21 -0700
Received: from map18.network49.183.tigo.net.gt
(map18.network49.183.tigo.net.gt [200.49.183.18]) by webmail.grupozisa.com
(Horde MIME library) with HTTP; Wed, 07 Oct 2009 10:57:17 -0700
Message-ID: <20091007105717.9fhhs1z9wok88o88@webmail.grupozisa.com>
Date: Wed, 07 Oct 2009 10:57:17 -0700
From: flopez@grupozisa.com
To: Rafa <rgalindo@adnsystems.com>
Subject: Re: Sistema
References: <4ACCBE3D.1000305@adnsystems.com>
In-Reply-To: <4ACCBE3D.1000305@adnsystems.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset=ISO-8859-1;
DelSp="Yes";
format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
User-Agent: Internet Messaging Program (IMP) H3 (4.1.6)

What best practice to use in this case, to allow these emails but blocking the others?

Regards

Greetings,

While we are aware that there are still those sectors out there that do not conform to Email server Best Practices, we feel that it is important to maintain such standards to not just help in spam identification, but also to ensure that future conformance is met.

As such, I do need to ask if you had attempted enabling just the one rule 'resolv_helo_domain' ? Based on the single example you have forwarded to us, that should ensure that particular one should pass, while the other would be stopped.

This being said, the 'check_dynamic_reverse_dns' rule is a particularly powerful one that should not be disregarded for those few cases of ISP's not conforming and/or services not being correctly configured. Bear in mind that you also have the option of utilizing the IP whitelist in the MagicSpam interface for those few cases of non-conformance, permitting a 'grace' period for said server administrators to properly configure their setup.

As well, an alternate approach is to create an entry in /etc/hosts on your Plesk server stating a proper name to work around these cases. For example:

200.49.183.18 mail.tigo.net.gt

would instruct your system to 'resolv' that source ip to a more conventional standard for your server.

We hope this information helps.