|
Peter,
Internet America requires that mail servers comply with RFCs. They need to interpret the RFCs correctly...
I fully agree with Dan on the stupidity of such decision. Disabling the VRFY is one of the 1st things many administrators do nowdays to help fight spammers.
I highlighted below the relevant sections of the RFC that's involved. You may want to explain the administrators of that ISP how the RFC actually works.
Roberto F.
LogSat Software
RFC 2821 states:
================
2.3 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described below.
1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that
the definition is an absolute requirement of the specification.
2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the
definition is an absolute prohibition of the specification.
3. SHOULD This word, or the adjective "RECOMMENDED", mean that
there may exist valid reasons in particular circumstances to
ignore a particular item, but the full implications must be
understood and carefully weighed before choosing a different
course.
... omissis...
.5.2 VRFY Normal Response
When normal (2yz or 551) responses are returned from a VRFY or EXPN
request, the reply normally includes the mailbox name, i.e.,
"<local-part@domain>", where "domain" is a fully qualified domain
name, MUST appear in the syntax. In circumstances exceptional enough
to justify violating the intent of this specification, free-form text
MAY be returned. In order to facilitate parsing by both computers
and people, addresses SHOULD appear in pointed brackets. When
addresses, rather than free-form debugging information, are returned,
EXPN and VRFY MUST return only valid domain addresses that are usable
in SMTP RCPT commands. Consequently, if an address implies delivery
to a program or other system, the mailbox name used to reach that
target MUST be given. Paths (explicit source routes) MUST NOT be
returned by VRFY or EXPN.
Server implementations SHOULD support both VRFY and EXPN. For
security reasons, implementations MAY provide local installations a
way to disable either or both of these commands through configuration
options or the equivalent. When these commands are supported, they
are not required to work across relays when relaying is supported.
Since they were both optional in RFC 821, they MUST be listed as
service extensions in an EHLO response, if they are supported.
7.3 VRFY, EXPN, and Security
As discussed in section 3.5, individual sites may want to disable
either or both of VRFY or EXPN for security reasons. As a corollary
to the above, implementations that permit this MUST NOT appear to
have verified addresses that are not, in fact, verified. If a site
disables these commands for security reasons, the SMTP server MUST
return a 252 response, rather than a code that could be confused with
successful or unsuccessful verification.
Returning a 250 reply code with the address listed in the VRFY
command after having checked it only for syntax violates this rule.
Of course, an implementation that "supports" VRFY by always returning
550 whether or not the address is valid is equally not in
conformance.
Within the last few years, the contents of mailing lists have become
popular as an address information source for so-called "spammers."
The use of EXPN to "harvest" addresses has increased as list
administrators have installed protections against inappropriate uses
of the lists themselves. Implementations SHOULD still provide
support for EXPN, but sites SHOULD carefully evaluate the tradeoffs.
As authentication mechanisms are introduced into SMTP, some sites may
choose to make EXPN available only to authenticated requestors.
|