[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [magicmail-users] Broken Exchange Server - Magic-SMTPD and you
Well, that is why the rule is meant to be selectable by the operators.. some,
prefer not to deal with the extra support calls generated, because people
expect to receive email from servers that are not set up to conform to best
practises. Even some Spammers are better at this than most admins :)
But there is a general philosophy that having rules like this do also have a
positive benifit on the internet as a whole. (ie... many ISP's did nothing
about outbound Spam until black listing became widely used) Administrators
who are lazy in one area, may be lazy in another and have other problems as
well. This allows the adminstrators who wish to go the high road, that
ability to do so. The valid HELO rule does not actually do reverse
resolution, because the HELO may represent an internal naming convention that
is not publicly identifiable (internal DNS) but it should be in a form that
represents a normal FQDN (fully quaiified), and this rule may be of a benifit
as an interim as well.
Amazing how many SPAM come from localhost.localdomain.
Normally, this rule is not used in the commercial version on NORMAL settings,
but it might appear on more STRICT settings.
Mail servers though, should be run by competent administrators that know the
basic best practises, including reverse DNS, DNS that indicates who the
operator is, HELO that identifies the server correctly, outbound rate
limiters etc..
The choice is now available for ISP's and their end users to make that
decision for themselves. And the added benifit of acting as a ZERO day
protector for new forms of Spam from originating from poorly written Spam
Engines, or mail servers that aren't properly maintained makes this
justifiable for most people. The majority of end users will never receive
legitimate email from anything but professionally run email servers.
The important thing is to NOT worry about your responsibilty to deal with
someone else's problems (their admins') but to properly and simply tell your
users, that the reason their mail did not get through, is the fault of the
sender's mail server, and not yours. And the more people that adopt rules
that only allow mail from properly configured mail servers, the quicker
administrators will fix their systems.
As more and more large scale ISP's, (and MagicMail customers) adopt best
practises rules, the quicker we will see more professionally run email
servers, and less opportunities for Spam to proliferate.
-- Michael --
On Tuesday 24 April 2007 15:36, Matt wrote:
> So,
> We turned magic-smtpd on and it, in combination with our RBLs and
> SpamAssassin has pretty much eliminated spam. There is one interested
> side effect.... that is that alot of Exchange servers seem to be being
> blocked because of the HELO domain not resolving... obviously they were
> setup by incompetent sys-admins who left the resolve domain set at
> something like srv1.northernlyco.local. We have been informing them that
> they need to change their domain to be something like
> srv1.northernlyco.org.
>
> Customer Service/Tech Support is asking that we remove the HELO resolve
> rule because of the delivery failures. We in Network Operations are
> holding that the Exchange servers are broken, and there is an easy fix.
>
>
> My question for the list is.... do you run with HELO resolving on.. and if
> so what do you tell the Exchange Admins?
--
--
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors - President/CEO - LinuxMagic
Products, Services, Support and Development
Visit us at http://www.linuxmagic.com
------------------------------------------------------------------------
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" is a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-589-0037 Beautiful British Columbia, Canada
This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.