How to know if I'm blacklisted

[Glenn Steen]

On 17/01/2008, Glenn Steen <glenn.steen at gmail.com> wrote:
> On 16/01/2008, Matt Kettler <mkettler at evi-inc.com> wrote:
> (snip)
> > The other part is your HELO is mail2.CANAL4. That really should be a valid
> > hostname. It's technically not against the RFC's to spew garbage here, but it
> > does show poor server administration, and some misguided sites seem to think
> > HELO must be a valid hostname and filter such things (the RFC's merely say
> > SHOULD, not MUST). You might want to fix the hostname your mailserver thinks of
> > itself as.
> >
> Um, not misguided as in "that could be anything". At least 2821 is
> pretty clear that the argument to EHLO (use of which is only a SHOULD
> in conjunction with the stipulation that "if you don't use EHLO you
> MUST use HELO", more or less) need be a FQDN, unless you are operating
> in a situation where such isn't valid (no valid reverse lookup or
> dynamic allocation of IP etc), in which case it "should" be an address
> literal... So rejecting on an invalid domain (or address literal)
> SHOULD be quite OK;-).
>
> In reality, there might be a few admins that get this wrong. Bah,
> couldn't care less, this drops a huge amount of spam for me.
>
> Cheers

Further... As you know, RFC821 isn't too specific about the argument
to HELO (which is all there is for older specs), but this is ...
rectified in RFC1123 (along with a few other protocols that weren't
that well defined from the start:-). Below is a quote of the section
about the HELO command, where it clearly states a MUST (which isn't
that clearly stated in the definition of EHLO in RFC2821, I'll grant
that:-). And in the DISCUSSION you see that the standard even suggest
rejection on *pure bad formatting* as a very viable option, with a
well-defined return. 2821 obsoletes (among others) and updates 1123,
so ... this is clearly a MUST and not SHOULD.
Go ahead and start using this Matt, it is very effective;-).
------------
      5.2.5  HELO Command: RFC-821 Section 3.5

         The sender-SMTP MUST ensure that the <domain> parameter in a
         HELO command is a valid principal host domain name for the
         client host.  As a result, the receiver-SMTP will not have to
         perform MX resolution on this name in order to validate the
         HELO parameter.

         The HELO receiver MAY verify that the HELO parameter really



Internet Engineering Task Force                                [Page 50]




RFC1123                  MAIL -- SMTP & RFC-822             October 1989


         corresponds to the IP address of the sender.  However, the
         receiver MUST NOT refuse to accept a message, even if the
         sender's HELO command fails verification.

         DISCUSSION:
              Verifying the HELO parameter requires a domain name lookup
              and may therefore take considerable time.  An alternative
              tool for tracking bogus mail sources is suggested below
              (see "DATA Command").

              Note also that the HELO argument is still required to have
              valid <domain> syntax, since it will appear in a Received:
              line; otherwise, a 501 error is to be sent.

         IMPLEMENTATION:
              When HELO parameter validation fails, a suggested
              procedure is to insert a note about the unknown
              authenticity of the sender into the message header (e.g.,
              in the "Received:"  line).
--------------

Cheers
-- 
-- Glenn
email: glenn < dot > steen < at > gmail < dot > com
work: glenn < dot > steen < at > ap1 < dot > se