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

[Glen <glen at amsl.com>]

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 ;-)  )

And as I was writing this, Danny just wrote in and said:

> But it does accept ANY dotted quad IP address (address
> literal):
> danny at pork% tn mail.ietf.org 25
> Trying 64.170.98.32...
> Connected to mail.ietf.org.
> Escape character is '^]'.
> 220 core3.amsl.com ESMTP Postfix
> HELO [0.0.0.0]
> 250 core3.amsl.com
> MAIL FROM: <glen at amsl.com>
> 250 2.1.0 Ok
> RCPT TO: <pwe3-chairs at ietf.org>
> 250 2.1.5 Ok
> DATA
> 354 End data with <CR><LF>.<CR><LF>
> EAT PORK
> .
> 250 2.0.0 Ok: queued as 96C3F28C10B
> NEWS TO SPAMMERS: USE ADDRESS LITERALS!
> I was dropping a ton of stuff on my personal servers because
> of this and had to disable it.

Whoops!  I was blocking numerics WITHOUT square brackets - I just added 
a rule to block them WITH.   Thanks for catching that!

> 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.

Meanwhile, as to the four rules at the top of the email, how shall we 
proceed?

Glen