allowing incoming email from your local domain

allowing incoming email from your local domain

am 22.02.2006 18:29:17 von ddk

I was wondering how many sites allow incoming Internet email with a
from address that matches the local domain? I put in blocks to stop
this but I have found a LOT of systems that expect to be able to send
to a our local domain using a from address that also uses our local
domain.

I am using sendmail.

Thanks
Dave

Re: allowing incoming email from your local domain

am 22.02.2006 21:02:54 von Mark Crispin

On Wed, 22 Feb 2006, ddk@rl.gov wrote:
> I was wondering how many sites allow incoming Internet email with a
> from address that matches the local domain? I put in blocks to stop
> this but I have found a LOT of systems that expect to be able to send
> to a our local domain using a from address that also uses our local
> domain.

Mailing list will send such messages; e.g., if fred@example.com sends a
message to the mailing list, fred will eventually get back a copy from
himself. More importantly, if sally@example.com is also on the mailing
list, sally will get a perfectly legitimate message from fred@example.com
that come from outside the domain.

It is wrong-headed, to say the least, to refuse incoming mail with a From
address that matches the local domain. Yes, spammers sometimes use a From
address that matches the local domain, but that's to get past a primitive
broken relay test that was fixed almost everywhere at least a decade ago.

Certain self-proclaimed "experts" with craniums shoved firmly up their
posteriors have a wrong-headed notion that mailing lists are required to
change the From address to be the name of the list. There is absolutely
nothing in any standard that requires this behavior. These individuals
are on a lonely crusade, much like the CR advocates.

As a mailing list administrator, my normal reaction is immediate expulsion
of the members on the offending SMTP server whenever I encounter an SMTP
server that rejects a message due to its From address matching the
server's local domain. When they complain, I tell them to get their SMTP
administrator to fix their server. If they don't notice/complain, they
didn't belong on the list in the first place.

However, this *does* mean is that the From address is irrelevant to any
relay testing. If you use the same SMTP server for both incoming and
outgoing mail (generally a bad idea in today's world), you must not trust
the From address as authorizing relaying.

A better method of dealing with the relaying issue is to have two separate
servers:
. one which refuses connections from the outside (and possibly also
requires authentication) and relays (an outgoing MTA)
. the other which allows connections from outside and refuses to relay
(an incoming MTA)
That way, the rules are straightforward. Security rule complexity is not
your friend.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Re: allowing incoming email from your local domain

am 22.02.2006 22:31:18 von ddk

Mark,

Thanks for the reply. We do have two separate MTAs. One for outgoing
email and internal email and one for incoming email. I have been
trying to block more spam and have seen a large number of messages per
day where their from address is our domain. I feel I am stuck since I
have no budget to install a SPAM system or to maintain one.

Thanks
Dave

Re: allowing incoming email from your local domain

am 22.02.2006 23:36:03 von Mark Crispin

On Wed, 22 Feb 2006, ddk wrote:
> Thanks for the reply. We do have two separate MTAs. One for outgoing
> email and internal email and one for incoming email.

Excellent!

> I have been
> trying to block more spam and have seen a large number of messages per
> day where their from address is our domain. I feel I am stuck since I
> have no budget to install a SPAM system or to maintain one.

There are some excellent freeware anti-spam systems; but unfortunately
that doesn't help with the maintenance budget. Sadly, spam-fighting is an
ongoing effort with substantial escalation occurring at both ends of the
battle.

Beware of snake oil peddlers claiming "perfect solutions". There are very
few "magic bullets", especially if your organization (from your email
address, I assume that it's government) can not tolerate false positives.

A kid on his home computer may be willing to have such extreme anti-spam
measures that he risks having a message from grandma getting dumped into
the spam bucket. In general, most academic, commerical, and government
sites err on the side of caution rather than risk a legitimate message
getting tossed.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Re: allowing incoming email from your local domain

am 23.02.2006 01:40:46 von Sam

This is a MIME GnuPG-signed message. If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.
The Internet standard for MIME PGP messages, RFC 2015, was published in 1996.
To open this message correctly you will need to install E-mail or Usenet
software that supports modern Internet standards.

--=_mimegpg-commodore.email-scan.com-30652-1140655246-0002
Content-Type: text/plain; format=flowed; charset="US-ASCII"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

ddk@rl.gov writes:

> I was wondering how many sites allow incoming Internet email with a
> from address that matches the local domain? I put in blocks to stop
> this but I have found a LOT of systems that expect to be able to send
> to a our local domain using a from address that also uses our local
> domain.

Perhaps you can try to solve this mystery simply by contacting those
apparent senders and asking them to explain their reasons for doing so.

This should be a rather enlightening experience.



--=_mimegpg-commodore.email-scan.com-30652-1140655246-0002
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQBD/QSOx9p3GYHlUOIRAqtwAJkBX+TOGd8OKQbTCh5+5rDKl78jZACb BvyS
vcRY334LosS0nyfWcjfCEDM=
=i+ht
-----END PGP SIGNATURE-----

--=_mimegpg-commodore.email-scan.com-30652-1140655246-0002--