>>> "Hisham Khalifa Al Saad" <webmaster @
admin .
uob .
bh> 10/14/96
11:28am >>>
>> Hi,
>>
>> The problem with SMTP servers as i noticed, is that they don't
>> authenticate users for the outgoing mail through their system by User
>> ID and Password like they do when checking recieved mail.
>>
>> Meaning, that anyone can use any SMTP server around the world to
>> be his outgoing SMTP server reducing the load on his own SMTP Mail
>> Server.
If one were to have her/his mail exchanger (MX) pass its mail to another
MX at another location, one must wonder what the purpose is. I'm
assuming the mail is being sent over the Internet for MX A to be able to
send to MX B, in the scenario you describe. If that's the case, then what
is the advantage? Unless the mail is _really_ destined for mail exchanger
B, there will always be one extra hop added to all mail delivery from MX
A. With regards to spool space, if MX B can not send out as fast as mail
comes in from MX A, MX B could run out of space. However, MX A will
only fill up too as it would have no where else to send its mail. If you are
painting a picture of a denial of service attack, that is unlikely too, as all
mail packages I'm familiar with accept mail only if/when they could handle
the load.
A person could also direct or bounce mail through a specific MX via UUCP
or 'hacked' SMTP style addressing with the same results (e.g.:
B!user @
domain, or user%domain @
B). As long as MX A is still
processing the outbound mail to get it to MX B, what is gained? No load is
pushed off of MX A. This type of "passthru mail" or "path routing" could
be limited/configured on some mail systems. In Sendmail, you could
disallow external transfer of mail originated from outside your domain.
In responding to your question, it's true that mail could be bounced off of
numerous MXs prior to hitting their final destination (and even that is
limited, due to loop-detection in many mail packages). I don't see this as
either a security or denial-of-service problem.
>> And thats not all, the other security breach which i also noticed, is that
>> anyone can simply steal other persons real name and e-mail address
>> without the need to know the password be cause it won't ask for it
>> for outgoing mail, and send any mail messages to anywhere by the
>> name of the stolen e-mail address.
Not everything needs to be stolen. It's quite easy to send mail from 'Elvis,'
and from what I've last read, he's not around anymore. Header spoofing
is as easy as 'echo "smtp_session..." | telnet MX 25'. While I agree this is
a security breach, the header doesn't lie. Every reasonable mail package
will attempt a reverse lookup on the MX sending in. If the address can't
be resolved, then the IP address will be placed in the header on one of
the Received-by: lines. Finding the culprit of spoofed e-mail tends to
depend on the action of the system administrator(s) of the system from
which the mail originated. For example, how many users have login
accounts on Compuserve systems (actual login accounts, other than the
system admins themselves)?
>> I have a Netscape Mail Server running on Digital Unix Alpha 1000.
>> I wonder if there is a solution for this problem, like for example, it
>> should ask for the User ID and Password for outgoing mail and not
>> only for checking incoming mail.
Are you sure this is a problem? Is the system being bogged down and
are you sure that it's due to mail passing thru your system? Have you
checked your logs to confirm the number of messages destined for
recipients on that system in relation to those not on your system?
If someone is, in fact, routing mail through your system (for some strange
reason), you could put in some kind of rule into the configuration file (I
don't know what that config file is for the Netscape mail server) which
either redirects those messages to /dev/null or prepends a warning
message to the effect of "following 12/1/96, all passthru messages will
be denied."
One last note - I wouldn't recommend having a mail exchanger accept mail
from the Internet destined for users on that same host. Mail exchangers
should be bastion hosts outside firewalls, inside DMZs containing Internet
connections.
Hope this helps.
- Harris Demel
(Former postmaster)
Novell Inc.
-------------------------
"Wherever you go, there you are."
|
|
