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
On Fri, Aug 29, 2003 at 10:38:15AM -0700, Bob Atkinson wrote:
There's a much simpler reason why rDNS is unreliable.
In order for rDNS to work, the domain owner must have a DNS relationship
with their ISP (as opposed to hosting DNS themselves). There are many,
particularly the small folk, who do not, esp. as it costs ongoing $ to
maintain such a relationship.
Having such a relationship is not today pragmatically necessary to
participate in the Internet, and we ought to think carefully before
giving ISPs such a win-fall and shift in power.
Bob
-----Original Message-----
From: asrg-admin(_at_)ietf(_dot_)org [mailto:asrg-admin(_at_)ietf(_dot_)org]
On Behalf Of
Hector Santos
Sent: Thursday, August 28, 2003 12:34 PM
To: Anti-Spam
Subject: Re: [Asrg] 0. General - Administrative - for M. Wild
David,
We found rDNS checking on HELO/EHLO to be unreliable due to
mis-configuration of smtp servers, in particular those systems who
prepare a
send-only or routing server, which from my last reading of the RFC (a
few
years back), need to be prepare as sub-domains. Because they are not,
it
is not possible to do reliable checking.
Recently, we added logic to check for the bracket DOT format, i.e,.
HELO/EHLO [X.X.X.X]
We found those servers using this format to be spammer servers and they
are
using it incorrectly, providing the literal IP without the brackets,
i..e,
HELO/EHLO X.X.X.X
So we reject the HELO/ELHO state when
a) The literal IP does not have brackets, or
b) The provided bracket IP does not match the connecting peer IP.
We have rejected on average about 125 per day using this scheme.
Incidentally, before this logic was added, the average about 80
attempts
per day. Hence, the rejection is causing some senders to try again more
often. We are sending a 5XX response code (permanent error, don't try
again) but some are ignoring it of course. :-)
----
Hector Santos
WINSERVER "Wildcat! Interactive Net Server"
http://www.santronics.com
----- Original Message -----
From: "David Wilson" <David(_dot_)Wilson(_at_)isode(_dot_)com>
To: "Yakov Shafranovich" <research(_at_)solidmatrix(_dot_)com>
Cc: <asrg(_at_)ietf(_dot_)org>
Sent: Thursday, August 28, 2003 4:00 AM
Subject: Re: [Asrg] 0. General - Administrative - for M. Wild
On Wed, 2003-08-27 at 14:24, Yakov Shafranovich wrote:
This message is intended for M Wild ("Mike"):
I have been trying to send an email reply to you but unfortunately
it is
not going through due to the following error:
450 Client host rejected: cannot find your hostname, [xx.xx.xx.xx]
I do not have an rDNS address and use the IP address in the HELO
command
for SMTP. Apparently your server is not accepting that. Please let
me
know
an alternative way to contact you.
RFC 2822 specifically allows domain literals in the EHLO/HELO command.
RFC 1123 Section 5.2.5 specific forbids refusing messages if the
domain
name in HELO (predating SMTP extensions, there is no mention of EHLO)
"fails verification".
There was general discussion some years ago about the issue of:
- accepting SMTP connections when there is no rDNS for the calling IP
address.
- accepting SMTP connections if the rDNS hostname does not have an A
record which contains the calling IP address.
At that stage there were enough legitimate sites which fail either of
these tests to make rejection on these grounds unacceptable for a
reasonable service.
So, in my opinion M Wild's MTA is not acting reasonably.
cheers
David Wilson
David(_dot_)Wilson(_at_)isode(_dot_)com
Isode Limited Tel: +44 (0) 20 8783 2961
http://www.isode.com
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg
--
Steven F. Siirila Office: Lind Hall, Room 130B
Internet Services E-mail: sfs(_at_)umn(_dot_)edu
Office of Information Technology Voice: (612) 626-0244
University of Minnesota
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg