Hello again, Alan.
> From: Alan Stebbens <aks@dokoka.ucsb.edu>
> It is not sendmail which is relying on the kindness of strangers, it is
> the system manager who has failed to configure it carefully enough.
>
> Sendmail is infinitely configurable, either by modifying its
> configuration rules, or by makeing the target addresses be aliases which
> filter the mail through programmable filters.
Well, this works in many cases, but not all. In the gwu.edu case, their
sendmail is being used as a mail relay only. Neither the source nor the
target address is known ahead of time, and neither is local. If they were,
then yes it is just a matter of talking sendmail into dealing with it.
Your advice is very valuable to most list admins, however, the issues
brought up are not list issues exactly, but go back to the deficiencies
in the SMTP standard which were discussed recently. It is peripherally a
list manager's issue though in the sense that lists were the main target
of the spams sent through gwu.edu, and many of us are also general
network/system/security admins so that these issues are also of interest.
But this also brings up another point in that sendmail is very flexible at
sorting and routing and making decisions in regards to the target address.
However, it is very poor on making decisions on the source mail address or
where it received the mail from. If the message is addressed to a network
address, it never gets down to a point where procmail could filter. And
if you don't know what the target is going to be, you can't put in
specific rewrites to get it out to an alias. To deal with this you need
to modify the sendmail source to add stuff to checkcompat() and/or add in
tcp wrappers. You could also use installed host routes pointing to
nowhere but this is kinda messy.
The big problem that everyone has been grumbling quietly about is that
sendmail will happily accept mail from *anyone* on the network addressed
to *anyone* outside your system and sendmail will go deliver it. There is
no checking to say "am I really supposed to accept mail from someone at
foo.com destined for bar.edu when I don't know either of these guys?"
This promiscuity is manifesting itself more and more in the following ways:
User gets Netscape and tells it that its SMTP server is "yourcompany.com"
because their friend at yourcompany has it set up that way and had
helpfully given out copies of his config files. yourcompany happily
accepts the mail and delivers it to whereever. It works so the user is
never the wiser that it is "wrong". The sysadmin at yourcompany doesn't
notice until he gets a stange bounce for an address he's never heard of.
The sysadmin discovers that a couple dozen other people also have their
Netscape set up the same way. After trying to get them to reconfigure and
noticing that most of them haven't done anything, he finally finds the
sendmail tcp wrappers patches in Usenet and effectively makes the errant
users cease to exist.
Kevin Spamzits has a few hundred thousand messages he wants to deliver,
he saves his 28.8kbps modem the effort and dumps the messages on
seas.dept.foo.edu to deliver. seas happily accepts the messages and then
takes on the brunt of the work in delivering them. The sysadmin of seas
implements some stopgap measures to stop it, but is always one step behind
since the source keeps changing.
Randy Mango has been having a running argument on a mailing list with
another member, Buzz Turner. One day he logs in to find he has been
unsubscribed by himself. The list manager examines the unsubscribe
request and finds it was inserted at a mail server at a site closely
associated with Buzz, but also with another list member and several
non-related accounts. However, the headers point only to a hostname so
nobody knows for sure if it was Buzz, or someone setting him up.
These are three real actual examples of what is being griped about. I'd
be extremely happy if I could configure sendmail in some way such that if
it receives a network messages, it is marked as "dirty" until it is
evaluated as coming from a site we relay from, or it is evaluated as going
to a site we relay to, or it goes through a local address expansion at
which point it is marked clean. If a "dirty" message is then scheduled to
go out over a network relay, then something is wrong and it should be
punted. I'd be ecstatic if this were to make it into the sendmail
distribution and therefore implemented at many sites, adopted by vendors
(eventually), etc.
The above formula should cover all legitimate uses. Mailing lists will
still work even for raw lists, since the local address expansion would
cause the message to be marked clean. Most sites can define legitimate
hosts or domains or IPs they will relay to/from. If there are other
problem areas, I'm sure they can be worked in.
Now, as was concluded in the March discussion, this goes against some of
the standards and also the good old Internet spirit. However, standards
are not static; we can change them if the reasons are good enough. I
believe that this change is very important to the sites which have been
victim of this problem. I think that the problem will only grow as more
and more people get on the net and more and more newbies who don't know
any better and opportunistic spammers take advantage of these problems.
Just these few little changes would cut down on a lot of forged mail and
make it easier to track the remainder. And about that Internet spirit
thing, well, it's a faint ghost of what it once was, and I fear the last
of it is already slipping away.
-- James Lick -- jlick@tcp.com -- http://drivel.com/jlick/ --
Follow-Ups:
|
|
