how to prevent fake email to enter my domain?

[Glenn Steen]

On 26/01/07, Michael Masse <mrm at medicine.wisc.edu> wrote:
> > Which would be along the line "If they're that stoopid they _should_
> > be dropped... Unless it affects a paying customer in a really bad
> > way"... I tend to think along the same lines, but scratch the last
> > part. If it is an issue, contact them, inform them that it is in
> > violation of RFC to do this... And if they fail to comply, well...
> Be
> > damned:-).
> > I've _never_ had any legitimate (business) sender that has failed to
> > see the light, when their error has been pointed out to them...
> ever.
> > On the contrary, most have (rather politely:) asked me to pass them
> > the brown bag:-D.
> >
> > But enabling "RFC strictness" do mean one has to at least keep a
> > fraction of an eye on it.
> >
>
> I totally agree with this in theory, but there have been cases where
> it's been impossible for the "sender" to change.   This usually occurs
> with hardware systems with embedded software which have the capability
> of sending alerts via email, such as our SAN hardware, our ethernet
> switches, and a certain SQL server written by a certain large company
> that should really know better.   Although I would love to think that
> Xiotech, EMC, Cisco, and Microsoft are going to push out firmware and or
> software fixes to become RFC compliant the instant I have a problem,  my
> experience has been that we are not considered a big enough player for
> them to bow down to.    In these cases I find that whitelisting the
> offending IP to be a solution that works quickly even if it's not the
> correct thing to do in principle.   I was originally trying to point out
> that the recipe to get helo checking installed is very easy, but if you
> need to make changes, such as whitelisting an IP, it's not clearly
> apparent if you're not proficient in sendmail's config language, so it
> might be good to find out how <before> you have an issue, regardless of
> how you handle it.
>
> My understanding (which I admit is very limited) of the helo stage is
> that to be RFC compliant you are supposed to send your domain, but it is
> also non compliant to reject an email if the sender is sending a bogus
> helo, and I believe this is what these major vendors hide behind,
> stating that I am breaking RFC compliance by rejecting their bogus
> helos.
>
> My apologies for taking this so OT.
>
> Mike

(A bit more sober today:-).
In principle you are right... For some things it can be a *tch to get
the thing to do the right thing.
At least the EMC and Cisco _should_ be able (with some config,
depending on flare/firmware of course) to do the right thing... But
whitelisting "internal" resources is of course OK... I'm thinking more
"external business email".
As to the "hiding behind RFC" argument... Wrong is wrong, and in  this
day and age... It is quite OK to just reject any violators.
A tad OT, yes... but still relevant methinks.

Cheers
-- 
-- Glenn
email: glenn < dot > steen < at > gmail < dot > com
work: glenn < dot > steen < at > ap1 < dot > se