hmm, on Wed, Mar 25, 2009 at 03:40:09PM +0100, Gilles Chehade said that
> Are you sure ?
just because you demonstrated a smtp session with
a questionably set up mail server it doesn't mean
you are right. sendmail by default does not check helo.
/etc/postfix/main.cf:
smtpd_helo_required = yes
smtpd_helo_restrictions =
reject_invalid_hostname
reject_unknown_hostname
reject_non_fqdn_hostname
these settings save any server a ton of work by not allowing
made up and incorrect helo's, one of the most reliable sign
of spam and clueless admins in general.
so let's play the rfc game then.
http://www.faqs.org/rfcs/rfc2821.html:
3.6 Domains
Only resolvable, fully-qualified, domain names (FQDNs) are permitted
when domain names are used in SMTP. In other words, names that can
be resolved to MX RRs or A RRs (as discussed in section 5) are
permitted, as are CNAME RRs whose targets can be resolved, in turn,
to MX or A RRs. Local nicknames or unqualified names MUST NOT be
used. There are two exceptions to the rule requiring FQDNs:
- The domain name given in the EHLO command MUST BE either a primary
host name (a domain name that resolves to an A RR) or, if the host
has no name, an address literal as described in section 4.1.1.1.
- The reserved mailbox name "postmaster" may be used in a RCPT
command without domain qualification (see section 4.1.1.3) and
MUST be accepted if so used.
4.1.1.1 Extended HELLO (EHLO) or HELLO (HELO)
These commands are used to identify the SMTP client to the SMTP
server. The argument field contains the fully-qualified domain name
of the SMTP client if one is available. In situations in which the
SMTP client system does not have a meaningful domain name (e.g., when
its address is dynamically allocated and no reverse mapping record is
available), the client SHOULD send an address literal (see section
4.1.3), optionally followed by information that will help to identify
the client system.
> HELO meeeeeeh
that is not an address literal or an fqdn.
my servers will reject that mail.
> Sendmail seems to disagree with you and the RFC does not mention a
> *requirement* to match the reverse DNS. In fact, if I recall
yes, the helo doesnt have to be the fqdn of the mail server
actually (it is in the role of an SMTP client in this case),
it can be any host. but it must an fqdn with a reverse dns
unless it is an adress literal.
> correctly it did mention that the server shouldn't or mustn't refuse a
> session based on what the client sends with its HELO/EHLO command.
based on 3.6 of course you can and should.
you can and should refuse any mail if any of the smtp
dialog is fishy.
helo is great for first perimeter defense. it throws away thousands
of dial up zombies without the need of spamassassin or greyfiltering.
legitimate users will see a legitimate error message they can
send to their admins.
-f
--
what part of no didn't you understand?
