Subject: [testlist] Rules for Rejecting Mail (was Re: Undelivered Mail Returned to Sender)

From: Glen <[email-masked]>
Date: Thu, 15 May 2008 20:04:13 -0700

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@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: <[email-masked]>
> 250 2.1.0 Ok
> RCPT TO: <[email-masked]>
> 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
_______________________________________________
Testlist mailing list
[email-masked]
https://mail.ietf.org/mailman/listinfo/testlist

---

From: "Eric Rescorla" <[email-masked]>
Date: Thu, 15 May 2008 20:38:31 -0700

On Thu, May 15, 2008 at 8:04 PM, Glen <[email-masked]> wrote:
>> and the check is still extant, perhaps it's time to revisit this decision,
>> or
> 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:
>
> 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.)
>
> 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.
>
> 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.

> 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

---

From: Glen <[email-masked]>
Date: Thu, 15 May 2008 20:44:44 -0700

> the defer with a check in SpamAssassin and, arguably, removing the

I read, and agree with this completely.

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

Agreed also.  Addressed in my other outage message, which crossed with 
this one.

Other comments from anyone regarding rules?

Thanks, Eric!

Glen

---

From: "Tom.Petch" <[email-masked]>
Date: Fri, 16 May 2008 13:51:42 +0200

Glen

You asked about reaching consensus and I think that that is an important part of
the culture of the IETF; it is a very flat organisation, although a few humps
and bumps have appeared over the years.

One of the more recent of these is the Administrative Director; it was he who
informed us of the changeover of provider, who kept us abreast of developments,
so it is he I see as your customer via whom requests such as those relating to
anti-spam measures should come.

I would expect him to consult, and the customary way to do so is via the IETF
main mailing list. However, e-mail is a topic where the list has many experts,
whose opinion may be divided, especially where spam is concerned, so I think
that achieving rough consensus there may be difficult.

There is also a dedicated anti-spam mailing list but that has even more experts
and I suspect that consensus will be even harder to reach there.

Nonetheless, I think that the process to follow is clear (and as I write this, I
am aware that achieving consensus on IETF process is even more fraught than
achieving consensus on e-mail:-(

Whatever the outcome, I believe that the Administrative Director should announce
it on the IETF and announce lists so that participants can adjust their DNS
entries etc accordingly.

Tom Petch

----- Original Message -----
From: "Glen" <[email-masked]>
To: "Eric Rescorla" <[email-masked]>
Cc: "Working Group Chairs" <[email-masked]>; <[email-masked]>; "David
Oran" <[email-masked]>; <[email-masked]>; "Danny McPherson" <[email-masked]>
Sent: Friday, May 16, 2008 5:44 AM
Subject: Re: [testlist] Rules for Rejecting Mail (was Re: Undelivered Mail
Returned to Sender)

---

From: James M Galvin <[email-masked]>
Date: Fri, 16 May 2008 09:48:46 -0400

-- On Friday, May 16, 2008 9:15 AM -0400 Barry Leiba 
<[email-masked]> wrote regarding Re: Rules for Rejecting Mail 
(was Re: Undelivered Mail Returned to Sender) --

> Jim says...
> > Eric, while your logic is correct it misses one critical point:
> > SPAMMER don't do this.  I'm not saying that no SPAMMERs do this
> > but I am saying that many SPAMMERs do not.
>
> I can't figure out what you're saying here.  Are you saying that
> these checks aren't meant to stop spam?  What, then?  (By the
> way, we write "spam" in lower case.  A small point, I grant,
> but....)

You're right.  As I reread it that is confusing.  Let's try this.

When it comes to SPAMMING logic does not apply.  I am saying that 
there is a class of SPAMMER that makes silly or uninformed mistakes 
and that we can use that to our advantage.  This rule falls in to 
that category.

Of course, not all rules work in all circumstances.

Please note, I'm neither arguing in favor of removing this rule nor 
in favor of keeping it.  I'm debating the reason that Eric is 
asserting supports removal of the rule.

He asserts we have one worked example of a false positive.  Well we 
don't.  RFC2821 clearly states in Section 3.6 that when domains are 
used in SMTP they must be resolvable.  Thus, Eric had a problem 
because his client was poorly configured.  That does not constitute 
a false positive in my opinion.

> > What matters is "does it work."
>
> That's too simplistic.  First, "works" means that it blocks spam
> *and* does not block legitimate traffic.  Second, it matters that
> it works in the long term, not just for today (see below).

I agree that we prefer long-term solutions, but along the way you 
have to go with what works.

> The HELO serves only to start the session and to identify the
> sending domain for the log file.  The domain that's given there
> is used for nothing -- nothing at all.  It's easy to think that
> it's reasonable to at least make sure that it's a valid domain
> for sending mail from (the purpose of test A, above), but the
> reality is that it can be bypassed by putting any domain at all
> there.  I can send email and use "HELO whitehouse.gov" and the
> receiving mail server will be happy.

As a practical matter this simply doesn't matter.  Checking the 
HELO works (blocks "bad", permits "good") and that is all that 
matters.  Granted, there may be a small percentage of the Internet 
community who might misconfigure their email client and thus be 
subject to blocking.  The question to be answered is whether anyone 
in the community of people contacting the IETF fall in to that 
category.  Yes, Eric fell in to the trap.  But he also "fixed" the 
problem immediately, which arguably was the right thing to do.

Therefore, if the rule is blocking undesirable email we should 
continue to use it.

>
> There've been proposals to validate the sending server's
> authority to use that domain (CSV, for example,
> http://mipassoc.org/csv/ ), and to actually use the domain for
> some purpose, such as checking it against a whitelist or
> blacklist. But unless it's *both* validated and used, there's no
> value in doing the DNS check.

I agree with you in principle but as a practical I disagree 
completely.  I agree that many rules, like this one under 
discussion, should not be offered as a guaranteed fail-safe against 
undesirable email.  However, that does not make the rule bad or 
ineffective.  It just means its value has to be evaluated in the 
environment in which it is to be used.

If the rule works for the IETF I do not see the problem.

> All of these checks seem wrong to me as currently implemented.
> And in general, I think it's a bad idea to use anti-spam
> techniques that address current spammer tactics that are easily
> changed once the spammers are aware of what we're doing. It's
> rather like rejecting mail that contains certain keywords: the
> spammers just start misspelling the words.  We long ago learned
> that that's a pointless skirmish, and that we need to fight more
> strategic battles.

I agree that we need to fight strategic battles, but along the way 
we have to win some tactical battles too.  If any rule blocks 
undesirable email while permitting valid email then it is a good 
rule.  The rules the IETF has in place, and has had in place for 
some time, are all good rules by that definition.

Jim

---

From: James M Galvin <[email-masked]>
Date: Fri, 16 May 2008 10:28:47 -0400

-- On Friday, May 16, 2008 8:24 AM -0600 Danny McPherson 
<[email-masked]> wrote regarding Re: Rules for Rejecting Mail (was 
Re: Undelivered Mail Returned to Sender) --

> Well, it's not binary, as has been demonstrated, and that's where
> the problem arises.  If it were, there'd be no issue.  It's not.

I was not aware that any email besides Eric's was having a problem.

Certainly, if the rule (or any rule for that matter) is blocking 
legitimate email then it is inappropriate for the IETF servers.

Jim

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 16 May 2008 11:26:20 -0400

> anti-spam measures should come.

The IAD acts on the behalf of the IAOC.

I agree, however, that consensus on this matter should be obtained on  
the IETF mailing list.
Consensus of working group chairs is not the same as IETF consensus.

Regards
Marshall

> Cc: "Working Group Chairs" <[email-masked]>; <[email-masked] 
> >; "David
> Oran" <[email-masked]>; <[email-masked]>; "Danny McPherson" <[email-masked] 
> >
>>> That's good, but I don't think it changes the fact that we need a  
>>> backup
> relay
>>> -Ekr
>>

---

From: James M Galvin <[email-masked]>
Date: Fri, 16 May 2008 11:39:12 -0400

-- On Friday, May 16, 2008 8:06 AM -0700 Eric Rescorla 
<[email-masked]> wrote regarding Re: Rules for Rejecting 
Mail (was Re: Undelivered Mail Returned to	Sender) --

> At Fri, 16 May 2008 10:28:47 -0400,
> James M Galvin wrote:

> > Certainly, if the rule (or any rule for that matter) is
> > blocking  legitimate email then it is inappropriate for the
> > IETF servers.
>
> So, as a corollary to this, you agree we should remove this rule?

I just went back through the messages and I could not find Danny's 
message.  Did I miss it?

You're not referring to the message about not handling bracketed IP 
addresses are you?  That was an implementation issue that Glen 
fixed.

Anyway, I don't have to see the evidence.  If it exists then, as I 
said, remove it.

Jim

---

From: James M Galvin <[email-masked]>
Date: Fri, 16 May 2008 13:02:43 -0400

-- On Friday, May 16, 2008 9:45 AM -0700 Eric Rescorla 
<[email-masked]> wrote regarding Re: [testlist] Rules for 
Rejecting Mail (was Re: Undelivered	Mail	Returned to Sender) --

>     * There MUST be a mechanism to complain that a message was
> inappropriately     blocked.
>
> If my mail system is configured in such a way that the rules
> we've been discussing kick in, what is the mechanism for me to
> complain?

This mechanism does not formally exist.  I noted this issue during 
the transition.

The informal method that exists for working groups is that folks 
can always contact the working group chair or other responsible 
person directly.  However, this does not speak to the issue of 
those who are not a participant.

There are choices that need to be examined, and perhaps the IETF 
should formally provide more than one way around any apparent 
blocking.

Regardless of what choice is made, the error message in the SMTP 
transaction when a message is "blocked" or "delayed" should provide 
a pointer to more information, i.e., it is common to have a web 
page that more fully explains what is happening and what can be 
done.

Jim

---

From: James M Galvin <[email-masked]>
Date: Fri, 16 May 2008 08:23:32 -0400

-- On Thursday, May 15, 2008 8:38 PM -0700 Eric Rescorla 
<[email-masked]> wrote regarding Re: Rules for Rejecting Mail (was 
Re: Undelivered Mail Returned to Sender) --

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

Eric, while your logic is correct it misses one critical point: 
SPAMMER don't do this.  I'm not saying that no SPAMMERs do this but 
I am saying that many SPAMMERs do not.

The efficacy of any given SPAM rule varies with its environment.  I 
don't know if this rule is "great" for the IETF but I do know it's 
a common rule.  It has a stricter version where the forward and 
backward DNS lookups are compared but that is usually more 
problematic.  The IETF does not use the strict version.

Of course there is the point of view that says that any false 
positive is too many, but then you got caught by this by having a 
poorly configured email client.  Once you fixed that the rule was 
not a problem for you, so I'm not inclined to count your rejection 
as a false positive.

Logic does not necessarily apply when it comes to SPAMMING.  What 
matters is "does it work."  To know whether this rule actually has 
a positive influence on IETF email (where "positive influence" 
means it rejects undesirable email), Glen would have to do some 
mail log analysis.  Do you think we should do this?

Jim

---

From: Danny McPherson <[email-masked]>
Date: Fri, 16 May 2008 08:24:01 -0600

> and that we can use that to our advantage.  This rule falls in to  

Perhaps.  But also note that there are spammers that do a
better job of implementing anti-spam mechanisms than the
'legit' folks do.

> a false positive in my opinion.

As did Dave Oran, and many others I suspect, especially
when folks are traveling and have no control over whether
an address is resolvable or not.

> have to go with what works.

Indeed, and if people are getting their mail dropped because
of this rule and don't know it, then that's a problem.  Don't call
it a false positive, call it what you want, but if we drop any legit
mail because of this rule then we've got a problem.

> As a practical matter this simply doesn't matter.  Checking the HELO  
> works (blocks "bad", permits "good") and that is all that matters.

>  Granted, there may be a small percentage of the Internet community  
> who might misconfigure their email client and thus be subject to  
> blocking.  The question to be answered is whether anyone in the  
> community of people contacting the IETF fall in to that category.   
> Yes, Eric fell in to the trap.  But he also "fixed" the problem  
> immediately, which arguably was the right thing to do.
>

No, I'd argue the inverse.  If the rule is blocking legit mail then
we should discontinue the use.

> If the rule works for the IETF I do not see the problem.

And if it were working without problem, we'd not be having this
discussion.

> some time, are all good rules by that definition.

Not if we drop good mail, that's the distinction and where we
disagree.  For example, the fact that there are many ways to
hack around HELO checks and spambots can (and ARE) be
updated in seconds with templates that accommodate these
types of trivial rules.

E.g., an address literal that employ empty IPv6 [IPv6:::] for
averting the HELO rule check.  Note that this is after Glen
updated the IPv4 address literal processing that last night
was accepting ANY valid dotted quad address (from 0.0.0.0
to 255.255.255.255):

danny@pork% telnet mail.ietf.org 25
Trying 64.170.98.32...
Connected to mail.ietf.org.
Escape character is '^]'.
220 core3.amsl.com ESMTP Postfix
HELO [IPv6:::]
250 core3.amsl.com
MAIL FROM: <[email-masked]>
250 2.1.0 Ok
RCPT TO: <[email-masked]>
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
DRINK MILK, IT DOES THE BODY GOOD!
.
250 2.0.0 Ok: queued as 1B9CD28C0D9

These rules, if they drop a single valid mail, are problematic,
I disabled them on my home servers because, ironically enough,
mail from several individuals AND iab.org were experiencing
transient failure conditions.

I don't want the uptick in spam anymore than anyone else, but
I also don't want legit emails to ietf.org lists dropped.

-danny

-danny

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 16 May 2008 08:06:58 -0700

> I was not aware that any email besides Eric's was having a problem.

Yes.

Danny forwarded a mail from Dave Oran that was blocked.

-Ekr

---

From: Danny McPherson <[email-masked]>
Date: Fri, 16 May 2008 09:56:07 -0600

> I just went back through the messages and I could not find Danny's  

Hrmm, that may have just been to Glen and the IAB list.

> addresses are you?  That was an implementation issue that Glen fixed.

No, it's not fixed with [IPv6::: ].

-danny

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 16 May 2008 09:45:54 -0700

At Fri, 16 May 2008 11:26:20 -0400,
> Consensus of working group chairs is not the same as IETF consensus.

I'd like to observe that the situation is of considerably broader
scope than just the IETF. There are certain addresses at (e.g.,
[email-masked], [email-masked]) that need to be accessible to those with
only a very peripheral relationship with IETF. For instance, when I
was on the IAB we used to receive various kinds of notifications from
governments, NGOs, etc. Because the current blocking occurs without
regard to destination address, this implies that those messages simply
get blocked. It's not like those people read the IETF mailing list and
are going to be aware of this policy.

In passing, I would note that because there is no bypass mechanism,
it's unclear how this practice is consistent with the final point
of the April 14 IESG statement on spam control:

    * There MUST be a mechanism to complain that a message was inappropriately
    blocked.

If my mail system is configured in such a way that the rules we've been
discussing kick in, what is the mechanism for me to complain?

-Ekr

---

From: Dean Willis <[email-masked]>
Date: Sat, 17 May 2008 04:31:17 -0500

>     records, not DNS failures, defer is just a particularly  

But it blocks the vast majority of spambot traffic without additional  
CPU loading. This rule combo blocks thousands of spams a day on my  
server; I'd guess it to be millions on the IETF boxes.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Sat, 17 May 2008 06:19:37 -0500

On May 17, 2008, at 4:31 AM, Dean Willis wrote:

>> cases

RETRACT: I'm actually rejecting on invalid domain name in MAIL FROM,  
not HELO. This is the default as of Sendmail 8.9, I believe.

The man page for sendmail describes this as

"Normally, MAIL FROM: commands in the SMTP session will be refused if  
the host part of the argument to MAIL FROM: cannot be located in the  
host name service (e.g., an A or MX record in DNS). "

It can be overridden with FEATURE(`accept_unresolvable_names)

I use a greet-pause (on unknown peers), reject unresolvable names,  
dnsbl using the Spamhause xen list, check for unresolvable local  
names;  then run spamassassin (spamd) post-delivery

So, yesterday I logged 188 greet-pause "failures"; 11 unresolvable  
names,  4346 dnsbl rejects, 332 unknown local users, 655 messages  
caught by SpamAssassin, and about 200 spams that made it past  
everything and had to be filtered out of my inboxes.

That does tell me that the number of unresolvable names is way down,  
since at one time it was one of the larger components of caught spam.  
Maybe EKR is right and this is no longer a particularly useful test.  
Or it may be that the dnsbl is killing them off first, and since IETF  
is unwilling to use a dnsbl, we might still need it.