I'm new to this mailing list so I don't know all that has been discussed. So
please excused any ignorance I may show.
I agree with Steven.
In my view, I believe ultimately the "mail server" concept will need to be
part of some official "registry" system. Whether that's going be done at
the HELO/EHLO state, one way or another, the system can not simply to
continue to work using the "honor" system and accept open-ended unauthorized
transactions.
At the same time, I don't think that is the complete solution either.
Before I go further, I would like to note that the cards may be already been
dealt for us. With more of the larger ISPs controlling access and limited
who can connect via HELO/EHLO and the peer IP, the developers, such as
myself, will follow their lead. So their actions may pre-empt any work
done here. Nonetheless, I am hoping to be part of any new specification
process and make sure I get my technical expertise and opinions heard.
In my view, we need a stronger handshake between the server and the client.
One way to accomplish this is using a "challenge string" as part of the
welcome.
250 domain, [vendor, version] [challenge string]
The compliant client will then use the challenge string as part of the EHLO
command. It can be a simple echo:
EHLO clienthosthame [challenge string]
At the very least, this will tell the server that the client is compliant
and ready for new commands that are engineered to complete an authorized
mail transaction.
or we can have a new command such MAILER that says:
MAILER clienthost [vendor, version] [challenge string]
regardless, we need to make this stronger and while we are at it, we use
the opportunity to enhance SMTP state machine.
Even if we consider to make stronger use of rDNS on the HELO/EHLO, we need
to make it strong enough to suggest that not everyone can just setup a mail
server to send mail. The larger ISPs are forcing the issue for us in this
regard
----
Hector Santos
WINSERVER "Wildcat! Interactive Net Server"
http://www.santronics.com
----- Original Message -----
From: "Bob Atkinson" <bobatk(_at_)Exchange(_dot_)Microsoft(_dot_)com>
To: "Steven F Siirila" <sfs(_at_)tc(_dot_)umn(_dot_)edu>
Cc: "Hector Santos" <winserver(_dot_)support(_at_)winserver(_dot_)com>;
"Anti-Spam"
<asrg(_at_)ietf(_dot_)org>
Sent: Friday, August 29, 2003 6:10 PM
Subject: RE: [Asrg] 0. General - Administrative - for M. Wild
Perhaps I'm being slow this Friday afternoon, but can you elaborate on
why you feel both rDNS and another DNS id is necessarily required to
deter Trojans? The reasoning you are using isn't clear to me.
Thanks much.
Bob
-----Original Message-----
From: Steven F Siirila [mailto:sfs(_at_)tc(_dot_)umn(_dot_)edu]
Sent: Friday, August 29, 2003 12:22 PM
To: Bob Atkinson
Cc: Hector Santos; Anti-Spam
Subject: Re: [Asrg] 0. General - Administrative - for M. Wild
Until we require both rDNS -AND- add another DNS identifier declaring
the
sending MTA as an MTA, we will continue to see trojan software
masquerading
as MTAs. While it may be a slow, painful process, I don't see any good
alternatives (at least not in our environment). We continue to employ
rDNS checking, adding more networks to the mix all the time. The key to
implementing rDNS for us has been:
1) It is not done for all IP addresses, but rather on a per-netblock
basis
(with the count of addresses having this requirement increasing each
day)
2) Users can opt-out of this requirement (the blocking occurs after
RCPT TO processing)
3) Even with the blocking in place, we return a URL to the sender to
allow them to request a block exception from our user who can then
either grant, deny, or ignore the request
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg