How to know if I'm blacklisted

Glenn Steen glenn.steen at gmail.com
Fri Jan 18 08:35:58 GMT 2008


On 17/01/2008, Matt Kettler <mkettler at evi-inc.com> wrote:
> Glenn Steen wrote:
> > 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;-).
>
> One thing, by your own citation, you MUST NOT use the verification of the HELO
> to refuse a message.
>
> So, using such validation to refuse mail is RFC non-compliant.

The magic is in:
-----
             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.
-----
... which is a bit further down. Your quote below is in regard to
doing an MX lookup on the string.

> > ------------
> >          However, the
> >          receiver MUST NOT refuse to accept a message, even if the
> >          sender's HELO command fails verification.
> >

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


More information about the MailScanner mailing list