Re: Rules for Rejecting Mail (was Re: Undelivered Mail Returned to Sender)

["Eric Rescorla" <ekr at rtfm.com>]

On Thu, May 15, 2008 at 8:04 PM, Glen <glen at amsl.com> wrote:
> Eric Rescorla wrote:
>> Glen,
>> It looks to me like mail.ietf.org is still rejecting mail from
>> machines which HELO with unknown hosts:
>> 450 4.7.1 <romeo2.rtfm.com>: Helo command rejected: Host not found
>> EHLO nonexistent.invalid
>> 450 4.7.1 <nonexistent.invalid>: Helo command rejected: Host not found
>> Did I misunderstand that you were going to suppress this check? If I did,
>> and the check is still extant, perhaps it's time to revisit this decision,
>> or
>> at least to check to see how often it's rejecting valid messages.
>> -Ekr
>
> Eric -
>
> Essentially so.
>
> When we did the cutover, we went over the rules the IETF wanted to use, and
> implemented them.  Amongst those rules WERE such elements as:
>
> A. Check that the HELO hostname has an "A" or "MX" record, defer if not.
> B. Check that the client IP address maps to a name; defer if not.
> C. Check that that name maps back to an IP address; defer if not.
> D. Check that the name->address mapping matches the client IP; defer
> if not.
>
> These were, in essence, rules given to us by the IETF at the time.
>
> So, when you reported your problem, I engaged members of the IETF transition
> team to comment; however, because it was the weekend, and everyone was gone,
> I just went in and (temporarily) removed "C" and "D" from the mix, so your
> mail would get through.  (You had added a host record, IIRC, so I didn't
> need to remove the other rules.)
>
> Although this "solved" the problem for you, which was great, I couldn't
> consider the matter "resolved" at this end, because although I am the IT
> Director at AMS, and the chief caretaker of the IETF servers, I don't feel
> good about just making (permanent) changes at the request of one individual,
> because there are so many conflicting views out there that I could be caught
> going back and forth forever!  :-)  I took out those two rules temporarily
> to solve your problem, pending discussion and consensus by the IETF about
> what "they" want, and direction from them to either restore the missing
> rules, leave things as-is, or remove additional rules.
>
> It's all fine for me either way, I'm just here to manage the servers and
> support the IETF as best I can.  But I was quite sternly lectured about the
> need for "consensus" on things like this - and our agreement says that we
> have to take aggressive anti-spam measures - so I am still hopeful that "the
> community" will engage in a decision-making process on this point, so we can
> get everyone on the same page.
>
> At this point, rules "A" and "B" are still active, "C" and "D" are removed,
> and I refer this back to the leaders of the IETF to discuss what they want,
> so I can implement it and make everyone happy.  (As much as that might be
> possible ;-)  )

As I indicated in my exchange with James, there's nothing stopping
a spammer from (1) registering a valid name and advertising
it in his HELO (2) simply advertising a totally random name that
doesn't map to his IP  in his HELO. Both of these measures will
evade rule (A), and indeed (2) is RFC 2821 compliant. Moreover,
as Danny observes, address literals are also RFC 2821 compliant
and appear to pass the current configuration.

Accordingly, here we have a situation where we have a rule that
is:

(1) easy for any spammer to bypass
(2) can be shown to have blocked legitimate mail in at least two cases
     [Note, you say "defer", but since the issue here is hosts without
     records, not DNS failures, defer is just a particularly inconvenient
     form of block.]

I think that presents a convincing argument for *at minimum* replacing
the defer with a check in SpamAssassin and, arguably, removing the
check entirely.



>> BTW: we should consider at least one backup relay for ietf.org
>> sometime real soon, especially if the outage issues aren't
>> completely resolved:
>
> I believe the outage issues are completely resolved at this point.  IN a
> separate email, I will describe what my conclusions are to everyone.

That's good, but I don't think it changes the fact that we need a backup relay

-Ekr