> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf
> Of Grzegorz Janoszka
> Sent: Wednesday, July 07, 2004 12:56 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [courier-users] Patch: two new options for checking HELO
>
> On Wed, 7 Jul 2004, Sander Holthaus - Orange XL wrote:
>
> > Just a quick question. As was reading up on my RFC and came across
> > RFC1123 which states that you MUST NOT reject bad HELO's? Is this
> > behaviour and that
>
> But some other RFC say that HELO MUST be a valid name :)
The RFC is a bit unclear about this. It says that MAY check the HELO, but
you MUST NOT reject bad HELO's EXCEPT if it does not have a valid
domain-syntax, in which case you MUST give a 501-error. I never saw a
501-error in Courier, so I take it that is not implemented? (Sam?).
Here the relevant part:
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
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).
>
> > of bofhcheckhelo "legal" to RFC 1123 or more current RFC's?
> Is RFC1123
> > superseded by some RFC (can't seem to find a RFC-repository
> that gives
> > me accurate information on this) which allows rejecting of
> bad HELO's?
>
> Rejecting bad HELO's is very efficient way to reject spam and
> viruses/worms without even receiving and checking the whole
> mail (saving cpu and net). If we want to be strict to RFC we
> can make all HELO checking disabled by default.
I know it is. But the thing is that Courier tries to be a MTA that is very
strict about RFC's and standards. This behaviour isn't RFC-complaint and I
never saw this mentioned anywhere. I think it SHOULD BE at least mentioned
that turning on BOFHCHECKHELO or BOFHNOVRFY (which MUST be enabled on most
installations) breaks RFC-compliance.
The problem here lies not with Courier so much, but mainly with the RFC.
It's from 1989 and has never been never updated/superseded and is really
really outdated on most points. I agree with the fact that Courier
implements behaviour to check the HELO-field, heck, if it wasn't so strict,
I would even use it. But since it breaks RFC-complaince, it must be cleary
metioned in the docs and configfile that it does.
Kind regards,
Sander Holthaus
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
courier-users mailing list
[EMAIL PROTECTED]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
