I ran into a problem the other day and I need some assistance. My email setup is a bit strange so I will explain.

our mx records point to the server with spam filter on it (like most of you) then once the email passes through spam filter the server forwards it to inself on a differnt port I designated where I have another commercial spam/virus/content filter setup to listen. This other product gets the message, insert disclaimers, checks for viruses etc. then it is forwarded to our exchange server. outbound email is sent from our exchange server to the sever with spam filter and the other email scanner on the port that I designated (not 25) so out bound email has disclaimers and virus checks and what not, then the email is sent out to remote servers. The outbound email never touches spamfilter, as it shouldn't.
This has been working awsome for several months without any problems......

Ok, with that said here is the problem.

A user tried to send an email to someone at airmail.net and immediately got a rejection message saying that mail can't be delivered to that domain. it works from yahoo and other places...
So I went to the web site and submitted a message on their support page as follows....

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.