Subject: Re: ietf.org mail blocking?

From: "Eric Rescorla" <[email-masked]>
Date: Fri, 9 May 2008 11:59:31 -0700

On Fri, May 9, 2008 at 11:40 AM, Eric Rescorla <[email-masked]> wrote:
> When I submitted my position paper today for the IETF RFC ,

Obviously, this should state "IETF P2P Infrastructure Workshop". Not
that it changes anything.

-Ekr

---

From: "Eric Rescorla" <[email-masked]>
Date: Fri, 9 May 2008 11:40:16 -0700

When I submitted my position paper today for the IETF RFC , I was a little
surprised not to get the promised acknowledgement. A little digging
around revealed that my mail was getting rejected by the IETF
mail server, first with a timeout during initial hello:

May  9 10:20:21 romeo postfix/smtp[13301]: 20EBC5081A:
to=<[email-masked]>, relay=mail.ietf.org[64.170.98.32]:25,
delay=304, delays=0.69/0.01/303/0, dsn=4.4.2, status=deferred
(conversation with mail.ietf.org[64.170.98.32] timed out while
receiving the initial server greeting)

and ultimately with a reverse resolution failure:

May  9 10:53:37 romeo postfix/qmgr[865]: 20EBC5081A:
from=<[email-masked]>, size=148644, nrcpt=1 (queue active)
May  9 10:54:49 romeo postfix/smtp[13621]: 20EBC5081A:
to=<[email-masked]>, relay=mail.ietf.org[64.170.98.32]:25,
delay=2372, delays=2299/0.02/72/0.02, dsn=4.7.1, status=deferred (host
mail.ietf.org[64.170.98.32] said: 450 4.7.1 Client host rejected:
cannot find your hostname, [74.95.2.173] (in reply to RCPT TO
command))

Note that my IP actually does resolve, though I admit not to the name
of my machine. You
can blame comcast for this one.

limbo-randy3:~> nslookup 74.95.2.173
Server:         66.33.216.127
Address:        66.33.216.127#53

Non-authoritative answer:
173.2.95.74.in-addr.arpa        name = 74-95-2-173-SFBA.hfc.comcastbusiness.net.

Note that (unsurprisingly), this doesn't apply just to p2pi. A test
message to [email-masked]
(to which I assure you I am subscribed) gets the same treatment.

May  9 11:37:45 romeo postfix/smtp[14705]: 0EBE750823:
to=<[email-masked]>, relay=mail.ietf.org[64.170.98.32]:25, delay=118,
delays=0.13/0.05/118/0.02, dsn=4.7.1, status=deferred (host
mail.ietf.org[64.170.98.32] said: 450 4.7.1 Client host rejected:
cannot find your hostname, [74.95.2.173] (in reply to RCPT TO
command))

Note that I used to be able to send mail to [email-masked] from this
machine just fine, so something
has change.

Not sure what's going on here, but this seems like a new and rather
undesirable configuration setting.

-Ekr

---

From: "Eric Rescorla" <[email-masked]>
Date: Fri, 9 May 2008 13:14:28 -0700

On Fri, May 9, 2008 at 12:53 PM, Glen via RT <[email-masked]> wrote:
> On Fri May 09 12:10:14 2008, [email-masked] wrote:
>> of my machine. You can blame comcast for this one.
> Hi Eric -
> I'm sorry you're encountering problems.
>
> We have not changed anything here recently, so I can't speak to the
> past, but let me tell you what I see from this end:

Well, I'm not sure what to tell you, because I haven't changed my configuration
either. Perhaps comcast has.

> Your machine HELO'ed as "romeo.rtfm.com"... except that host doesn't
> seem to exist or resolve:
>
> core3:/home/glen # host romeo.rtfm.com
> Host romeo.rtfm.com.amsl.com not found: 3(NXDOMAIN)
>
> And while your IP address does resolve at this time:
> core3:/home/glen # host 74.95.2.173
> 173.2.95.74.in-addr.arpa domain name pointer
> 74-95-2-173-SFBA.hfc.comcastbusiness.net.
>
> ... it is possible that, earlier, it wasn't resolving.

Well, you're still rejecting my mail. Perhaps the problem is that there
is no forward record for 74-95-2-173-SFBA.hfc.comcastbusiness.net.

> At any rate, I'm happy to do whatever you like, but I disagree that
> rejecting obviously differing data is undesirable, simply because of the
> strong desire of "the community" to be spam-free.

I'd be interested to know if you have any data that indicates that this
kind of check has any impact whatsoever on spam.  If not, this is just
a gratuitous source of false positives.

I'm also not sure I agree with your characterization of the desires of
the community. In particular, the IESG statement on spam control
http://www.ietf.org/IESG/STATEMENTS/spam-control-policy.html
says:

* IETF mailing lists MUST provide a mechanism for legitimate technical
participants to bypass moderation, challenge-response, or other techniques
that would interfere with a prompt technical debate on the mailing list
without requiring such participants to receive list traffic.

But since my mail is being blocked before it ever gets to the MLA, this
check would seem to violate this requirement.

> Would it be possible for you to add your host to your domain so it
> resolves?  Would it be possible for Comcast to reverse-delegate your IP
> block to you, or set up more accurate reverse resolution records for
> you?  Would it be possible for your outgoing mail to relay through your
> ISP's authoritative mail server, to ensure that resolution works?

I regularly send mail from my laptop with dynamic addresses, so, no,
none of these things will work reliably for me.

> Here are things I can do to compensate:
>
> 1. I could whitelist your IP address in our access tables (pointless if
> you're dynamic).
>
> 2. I could whitelist your "rtfm.com" domain (very cool name) in our
> access tables.  Or your email address.
>
> Or, of course, I could gloablly disable the check for invalid hostnames
> systemwide.

This is a category error. They're not invalid hostnames. They're hostnames
that don't appear in the DNS, which is not the same thing at all.

> Also, I've cc'ed the wgchairs list on this response - because you cc'ed
> them on your ticket filing - but I cannot leave the list as a permanent
> ticket cc because of the potential for floding.  So when you file a
> ticket, I'd recommend not cc'ing the whole world - or at least not
> mailing lists - since RT can be a bit, umm, "difficult" about things
> like that.

Actually, you didn't cc wgchairs. I've fixed that and replaced the ietf-action
mail with your direct address to avoid excessive ticket creation.

-Ekr

---

From: Barry Leiba <[email-masked]>
Date: Fri, 09 May 2008 16:46:45 -0400

> mail with your direct address to avoid excessive ticket creation.

And for the record, Glen, since I inferred from one of your messages that you'd 
prefer to sort this out offline and post the result -- and I understand that: I, 
for one, would like to see the discussion continue here on the list.  Seeing the 
intermediate considerations and discussion is both interesting and useful.

Barry

--
Barry Leiba, DKIM working group chair  ([email-masked])

---

From: Glen <[email-masked]>
Date: Fri, 09 May 2008 13:56:07 -0700

Not a problem.

I've escalated this up to Jim Galvin - who helped set the rules and tone 
for spam processing.  He is discussing this with Russ and others now.

It's an easy thing to disable the checks - I'm just not comfortable 
doing that arbitrarily, when finding a way to bring the other host into 
more standard conformity might be an option.  So I've sent this back to 
the IETF to let them determine how they want to proceed.

Glen

Barry Leiba wrote:
> And for the record, Glen, since I inferred from one of your messages 
> that you'd prefer to sort this out offline and post the result -- and I 
> understand that: I, for one, would like to see the discussion continue 
> here on the list.  Seeing the intermediate considerations and discussion 
> is both interesting and useful.
> 
> Barry
> 
> --

---

From: "Eric Rescorla" <[email-masked]>
Date: Fri, 9 May 2008 14:48:17 -0700

On Fri, May 9, 2008 at 2:15 PM, James M Galvin <[email-masked]> wrote:
>
>
> -- On Friday, May 09, 2008 1:14 PM -0700 Eric Rescorla <[email-masked]> wrote
> regarding Re: [rt.amsl.com #7269] ietf.org mail blocking? --
>
>> > Your machine HELO'ed as "romeo.rtfm.com"... except that host
>> > doesn't seem to exist or resolve:
>> >
> Eric,
> As I understand it, your email was delayed (not rejected since the return
> code was 4xx) because the name in the HELO does not exist. It has nothing to
> do with the IP address.

You're making several observations here:

- That the mail was delayed (not rejected). I agree that this is notionally a
   transient error (because DNS sometimes fails) but it's not like it's going
   to fix itself, right? More like my mailer will keep trying and
eventually give
   up. That actually seems worse than immediate rejection since it takes
   days to get a bounce.

- I'm not an expert on reading the mail logs, but it actually looks more to
  me like its related to the reverse name resolution, given the listing of
  the IP here.

Client host rejected: cannot find your hostname, [74.95.2.173] (in
reply to RCPT TO command))

Perhaps it's the forward lookup on the reverse mapping for
74-95-2-173-SFBA.hfc.comcastbusiness.net

> Have you always done this?

Not always, but there hasn't been an A record for "romeo.rtfm.com" for
over a year
and it worked fine till at least 5/5 (which was the last time before today that
I tried to send mail through ietf.org).

> It should be the case that the IETF servers do not take messages from hosts
> that do not exist.

1. The host does exist. It just doesn't have a DNS entry.
2. Why should this be the case?

> The IETF does not apply strict connection controls but it seems reasonable
> to me to reject apparently "anonymous" messages.

What makes the message anonymous? I'm advertising "[email-masked]" in
my MAILTO.

I'm not trying to be difficult, but I'd appreciate it if you could work through
the logic for me of what checks you believe the system is doing and why
you think they are useful.

Here's my reasoning.

It seems to me that there are at least four potential values here:

(1)The IP address of my MTA.
(2) The domain name you get when you reverse lookup (PTR) the IP.
(3) The hostname my MTA advertises in HELO
(4) The RHS of the email address that my MTA sends in MAIL FROM

Here's what I believe to be true:

1. You can't require that values (3) and (4) match because my MTA
    might be relaying. In fact, it is, since I'm sending from "romeo.rtfm.com"
   but my email address is "[email-masked]"

2. Given that I control the domain "example.com", I can put anything I want
    in "foo.example.com", so if I'm a spammer I can arrange that forward
    lookups for value (3) always succeed. Moreover, I can arrange that they
    match value (1)

Given the above two facts, I don't see how checks that involve only
forward lookups from value (3), the HELO value, are useful. In principle,
lookups from the MAIL FROM value (4), might be useful if they somehow
could be tied back to the message (e.g., via SPF or DKIM), but one
can't insist on that given the current state of the network.

Given the above, I don't see how rejecting on failures to resolve values (3)
or (4) make sense from an anti-spam perspective.

This brings us to the topic of values (1) and (2), about which I believe
the following:

0. In general the reverse mapping part of the tree is a mess.
1. That the ISP in general controls the relevant portion of the in-addr tree
    (though they may of course delegate).
2. That ISPs often do populate that section of the tree, but (especially with
    dynamic addresses) the values are synthetic, meaningless names,
    like the one above (i.e., <ip>.provider-domain.)
3. That sometimes those meaningless names forward resolve and sometimes
    they don't.
4. That there are some cases where users can get control of the in-addr
    part of the domain and some cases (dynamic IPs again) where they can't.

Because of point (2) you can't check that value (2) matches value (3) or
value (4). At best you can check that the reverse mapping exists and
that the forward mapping exists. However, the problem here is that
because of point (0), this causes spurious rejections, and therefore only
makes sense if it's significantly harder for spammers to get the
reverse/forward parts of the tree in shape than it is for ordinary
users. Why would this be so?

What have I missed?

Thanks,
-Ekr

---

From: James M Galvin <[email-masked]>
Date: Fri, 09 May 2008 17:15:12 -0400

-- On Friday, May 09, 2008 1:14 PM -0700 Eric Rescorla 
<[email-masked]> wrote regarding Re: [rt.amsl.com #7269] ietf.org 
mail blocking? --

Eric,

As I understand it, your email was delayed (not rejected since the 
return code was 4xx) because the name in the HELO does not exist. 
It has nothing to do with the IP address.

It should be the case that the IETF servers do not take messages 
from hosts that do not exist.  It should also be true that they 
don't care if the IP address and name do not match, for exactly the 
reason you describe.

The IETF does not apply strict connection controls but it seems 
reasonable to me to reject apparently "anonymous" messages.

Jim

---

From: James M Galvin <[email-masked]>
Date: Fri, 09 May 2008 21:49:53 -0400

A short answer to you is the following.

RFC 2821 clearly states in Section 3.6 that:

    Only resolvable, fully-qualified, domain names (FQDNs)
    are permitted when domain names are used in SMTP.

However, perhaps we (the IETF) want to be a bit more generous in 
what we accept, so I've commented more fully inline.  As always, 
"rules" can be changed.

-- On Friday, May 09, 2008 2:48 PM -0700 Eric Rescorla 
<[email-masked]> wrote regarding Re: [rt.amsl.com #7269] ietf.org 
mail blocking? --

> - I'm not an expert on reading the mail logs, but it actually
> looks more to   me like its related to the reverse name
> resolution, given the listing of   the IP here.
>

It looks that way, I agree.  I'm told it doesn't mean that but I've 
asked Glen to double check so we can be sure.

> Not always, but there hasn't been an A record for
> "romeo.rtfm.com" for over a year
> and it worked fine till at least 5/5 (which was the last time
> before today that I tried to send mail through ietf.org).

When you say "no A record", do you mean it was not listed in the 
DNS or just that it did not have an A record?

> > It should be the case that the IETF servers do not take
> > messages from hosts that do not exist.
>

While the host may certainly exist, presence in the DNS is commonly 
used as a weak authoritative existence test.  The assumption is 
that a process, albeit a weak one, was exercised to approve the 
presence in the DNS.

The obvious counter-argument is that a SPAMMER could own the domain 
they're using and put anything they want in the DNS.  The argument 
is valid to the extent that SPAMMERS are not taking steps to hide 
their existence or identity.  While there are many ways to slice 
the "email pie" to find the bad parts (the SPAMMERS), I think we 
can at least agree that connection sources who are attempting to 
hide their existence or identity are SPAMMERS.  For those cases, 
this test is just one mechanism among many that is helpful in the 
fight against SPAM.

Of course it's valid to ask how effective this is for the IETF.  I 
don't know offhand but I'm sure if we're interested in that 
statistic we could probably arrange for it to be gathered and made 
available.

> What makes the message anonymous? I'm advertising "[email-masked]"
> in my MAILTO.

I'm using "anonymous" to mean that the origin of the connection is 
not clearly identifying itself.  Yes, it could "lie" to get past 
this particular check but that's exactly the point.  It's not even 
trying to "do the right thing".

> I'm not trying to be difficult, but I'd appreciate it if you
> could work through the logic for me of what checks you believe
> the system is doing and why you think they are useful.

No problem.  I'm all for change, too, if folks believe that 
something else is more appropriate.

> (4) The RHS of the email address that my MTA sends in MAIL FROM

Agree.

>     might be relaying.

I agree.

> 2. Given that I control the domain "example.com", I can put
> anything I want     in "foo.example.com", so if I'm a spammer I
> can arrange that forward     lookups for value (3) always
> succeed. Moreover, I can arrange that they     match value (1)

This is all true.  This is why these tests contribute to a SPAM 
score via SPAMASSASSIN but are not otherwise definitive tests.

The only definitive test being employed here is the simple test of 
whether or not a client is correctly configured, i.e., is it 
identifying itself?  This is a very minimum configuration setting. 
In fact, it's darn near the first thing you have to set when 
installing any email application, whether it's a client or a 
server, which is "what is my name?"  In my opinion if you can not 
get your own name right then anything you do should be immediately 
suspect.

Of course, 'getting it right' means doing two things.  First, the 
application has to know what its name is.  Second, that name also 
has to be somewhere it can be confirmed, in this case the DNS. 
Yes, I agree, this test is weak, but it is a commonly accepted 
practice.

Of course, the IETF could choose to do things differently if we 
don't like this rule.

> Given the above two facts, I don't see how checks that involve
> only forward lookups from value (3), the HELO value, are useful.

I wouldn't do a forward lookup on 3 to compare to 4.  Relaying 
makes that impractical.  However, it is a common practice to do the 
forward lookup on 3 and compare it to the value in 2.  This test 
does not work well in all environments (perhaps many), but it can 
be used to contribute to a SPAM score effectively.

> In principle, lookups from the MAIL FROM value (4), might be
> useful if they somehow could be tied back to the message (e.g.,
> via SPF or DKIM), but one can't insist on that given the current
> state of the network.

Agreed.

> Given the above, I don't see how rejecting on failures to resolve
> values (3) or (4) make sense from an anti-spam perspective.

As a general rule I agree.  However, the specific test here is 
whether or not the name exists.  Testing for existence, even if it 
is a lie, is a good thing.  The credibility of the value is tested 
later by SpamAssassin.

> This brings us to the topic of values (1) and (2), about which I
> believe the following:
>
> 1. That the ISP in general controls the relevant portion of the
> in-addr tree     (though they may of course delegate).
> 2. That ISPs often do populate that section of the tree, but
> (especially with     dynamic addresses) the values are synthetic,
> meaningless names,     like the one above (i.e.,
> <ip>.provider-domain.)
> 3. That sometimes those meaningless names forward resolve and
> sometimes     they don't.
> 4. That there are some cases where users can get control of the
> in-addr     part of the domain and some cases (dynamic IPs again)
> where they can't.

Agree to all this.

> Because of point (2) you can't check that value (2) matches value
> (3) or value (4). At best you can check that the reverse mapping
> exists and that the forward mapping exists. However, the problem
> here is that because of point (0), this causes spurious
> rejections, and therefore only makes sense if it's significantly
> harder for spammers to get the reverse/forward parts of the tree
> in shape than it is for ordinary users. Why would this be so?

It is true that people can "lie" and this is checked in 
SpamAssassin and contributes to the SPAM score of a message.  The 
only mechanism employed at connection time is the most basic 
configuration check.  If the origin of a connection can not make 
any attempt to identify itself in a way that can be verified, even 
weakly, then that origin is summarily suspicious.

Jim

---

From: Henrik Levkowetz <[email-masked]>
Date: Sat, 10 May 2008 10:38:22 +0200

James,

On 2008-05-10 03:49 James M Galvin said the following:
<snip long back-and-forth>

> weakly, then that origin is summarily suspicious.

I've used failed forward and reverse lookups of the HELO and MTA IP
for a long time as spam indicators in Spamassassin's rules, and they
*are* useful spam indicators, but I think that summarily rejecting
mail on this one check is summarily bad.  James, I'f you've had this
absolute condition added to the IETF mail setup, then please have it
removed again and let Spammassassin use these lookups as two among
its hundreds of weighted checks.

That seems sane to me; the current situation doesn't.

	Henrik

---

From: "Eric Rescorla" <[email-masked]>
Date: Sat, 10 May 2008 06:18:46 -0700

On Fri, May 9, 2008 at 6:49 PM, James M Galvin <[email-masked]> wrote:
> However, perhaps we (the IETF) want to be a bit more generous in what we
> accept, so I've commented more fully inline.  As always, "rules" can be
> changed.

OK. That's fair. I'd quibble with the argument that the server should
be blocking
mail that doesn't conform to this (be liberal in what you accept,
etc.) but I've added the appropriate
record for romeo.rtfm.com. It doesn't seem to help.

> When you say "no A record", do you mean it was not listed in the DNS or just
> that it did not have an A record?

I mean that it's not been listed in the DNS at all. Not that it really matters,
since S 3.6 quite clearly
states that names appearing in EHLO must resolve to A records:

  -  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

So, this is some new behavior we're observing.

As noted above, I believe my domain is now configured to pass the test
you say this system is enforcing, but mail.ietf.org is still rejecting my
mail.

The rest of this message is me arguing that this test isn't appropriate,
but that's no longer the high order bit.

> While the host may certainly exist, presence in the DNS is commonly used as
> a weak authoritative existence test.  The assumption is that a process,
> albeit a weak one, was exercised to approve the presence in the DNS.
>
> The obvious counter-argument is that a SPAMMER could own the domain they're
> using and put anything they want in the DNS.  The argument is valid to the
> extent that SPAMMERS are not taking steps to hide their existence or
> identity.  While there are many ways to slice the "email pie" to find the
> bad parts (the SPAMMERS), I think we can at least agree that connection
> sources who are attempting to hide their existence or identity are SPAMMERS.

Well, I'm not a spammer, so either this assertion is wrong or people not
representing correct identities is a lousy test for people attempting to
hide their existence. Take your pick.

>  For those cases, this test is just one mechanism among many that is helpful
> in the fight against SPAM.

Huh? Why is this so? Say I do "EHLO mail.ietf.org"? That's a perfectly
valid domain
name and it maps to an IP address. It just doesn't happen to be mine. This
only becomes a useful check when you compare it to the address that I'm
actually coming from.

> I'm using "anonymous" to mean that the origin of the connection is not
> clearly identifying itself.  Yes, it could "lie" to get past this particular
> check but that's exactly the point.  It's not even trying to "do the right
> thing".

I don't find this particularly convincing. It's identifying itself by
IP address.
Given that that's a lot harder to spoof than domain name, I wouldn't
use the term anonymous...

> It is true that people can "lie" and this is checked in SpamAssassin and
> contributes to the SPAM score of a message.  The only mechanism employed at
> connection time is the most basic configuration check.  If the origin of a
> connection can not make any attempt to identify itself in a way that can be
> verified, even weakly, then that origin is summarily suspicious.

As noted above, I question that claim.

-Ekr

---

From: "Eric Rescorla" <[email-masked]>
Date: Sat, 10 May 2008 06:15:01 -0700

So, I believe this is some new behavior we're observing.

As noted above, I believe my domain is now configured to pass the test
you say this system is enforcing, but mail.ietf.org still seems to be
rejecting my email. What now?

-Ekr

---

From: Glen <[email-masked]>
Date: Sat, 10 May 2008 08:38:06 -0700

> That seems sane to me; the current situation doesn't.

And I certainly didn't want this to escalate into something this involved.

AFAIK this check has been in there since cutover, and I can't speak for 
why it's suddenly become exposed... but in the interest of getting a 
quick resolution, even if a temporary one, I've modified the ruleset here.

Eric, could you please test this and let me know how it goes?  If it 
fails again, we can try something else.

Thanks,
Glen

---

From: Glen <[email-masked]>
Date: Sat, 10 May 2008 09:19:24 -0700

Eric Rescorla wrote:
> Yeah, things got through... though it looks like there is still some timeout
> in play since it took a long time for the queue to flush.

Okay, I've put a modification in to stop the check that was failing for 
you, and I'm glad that solved it for the moment.

I see you're all in a debate over this, but - ha ha - I'm "supposedly" 
off this weekend, and didn't want your mail to sit there all weekend long.

If further changes in either direction are needed, just let me know.

Also since I have everyone's attention for a moment, may I just clarify 
my previous statements about RT and CC'ing people?

Under the current setup of RT+TMDA+MAILMAN+everything else, we've found 
the following:

1. If someone sends a ticket to RT -and- other addresses, regardless of 
which addresses are in To: or CC: or BCC: fields, the ticket is set up 
by RT to only respond to the originator, and NOT to all the other 
people/addresses that were CC'ed.

2. Even if we then manually add all the other addresses from the 
original submission to the ticket, mailing list addresses tend to still 
not get traffic from RT.

Being flooded with other things, I do not subscribe to the WG chairs 
mailing list (or pretty much any mailing lists anywhere in the world), 
but I get the impression that many of you like to be involved in 
discussions of this type.

I have no problem with this.  RT, otoh, apparently does.

It's not a deal where I want to handle things offline - quite the 
opposite - I am happy to have everyone involved and chiming in (at least 
at this level) - but with RT we've found that people get cut out of 
threads and don't always see responses - so it's more accurate to say 
that I prefer to handle things over direct email.  It's much faster and 
easier for me, and it ensures that everyone stays in the loop.

Any of you on the wgchairs list, the testlist, or who are cc'ed on this 
message are welcome to email me directly at any time.

You're also welcome to open tickets.  But if you see someone open a 
ticket, and then you don't see any follow-up, please know that we -are- 
dealing with the request, you just might not see the follow up because 
of interactions with RT.

But email will always get my personal attention much more quickly.

Have a good weekend, all, and let me know if anything else is needed!

Glen

---

From: Glen <[email-masked]>
Date: Sat, 10 May 2008 10:45:41 -0700

Eric Rescorla wrote:
> Sadly, we're not there yet.
> I'm still getting:
> May 10 09:28:59 romeo postfix/smtp[90029]: 884635081A:
> to=<[email-masked]>, relay=mail.ietf.org[64.170.98.32]:25, delay=945,
> delays=623/0.02/322/0, dsn=4.4.2, status=deferred (conversation with
> mail.ietf.org[64.170.98.32] timed out while receiving the initial
> server greeting)
> At least some of the time.

Odd.  Here's what I see from your IP, after modifying the ruleset:

We got a message at 08:36:34 (we're on PDT=GMT-7 here) from you to tls, 
message-id=<[email-masked]>, and it was 
accepted and went right through to the list.

At 08:44:32, message [email-masked] to 
p2pi-com was accepted and put through.

At 08:53:51, message [email-masked] to tls was 
accepted and put through.

There is no more traffic from your IP address until 10:06:11, when we 
got this:

May 10 10:06:11 core3 postfix/smtpd[1379]: connect from unknown[74.95.2.173]
May 10 10:06:11 core3 postfix/smtpd[1379]: lost connection after CONNECT 
from unknown[74.95.2.173]
May 10 10:06:11 core3 postfix/smtpd[1379]: disconnect from 
unknown[74.95.2.173]

Mail is still flowing in to our servers from lots of other sources - 
I'll keep watching.

Glen

---

From: "Eric Rescorla" <[email-masked]>
Date: Sat, 10 May 2008 08:54:59 -0700

On Sat, May 10, 2008 at 8:38 AM, Glen <[email-masked]> wrote:
> AFAIK this check has been in there since cutover, and I can't speak for why
> it's suddenly become exposed... but in the interest of getting a quick
> resolution, even if a temporary one, I've modified the ruleset here.
>
> Eric, could you please test this and let me know how it goes?  If it fails
> again, we can try something else.

-Ekr

---

From: Glen <[email-masked]>
Date: Sat, 10 May 2008 10:54:53 -0700

Hmmm.

This just came in:

May 10 10:53:11 core3 postfix/smtpd[16318]: connect from 
unknown[74.95.2.173]
May 10 10:53:11 core3 postfix/smtpd[16318]: NOQUEUE: reject: RCPT from 
unknown[74.95.2.173]: 550 5.1.1 <[email-masked]>: Recipient 
address rejected: User unknown in virtual alias table; 
from=<[email-masked]> to=<[email-masked]> 
proto=ESMTP helo=<romeo.rtfm.com>
May 10 10:53:11 core3 postfix/smtpd[16318]: disconnect from 
unknown[74.95.2.173]

Do we have a new problem, or did you send a message to 
"[email-masked]" deliberately?

Glen

---

From: "Eric Rescorla" <[email-masked]>
Date: Sat, 10 May 2008 10:56:49 -0700

That was intentional. I wanted to see if I could capture a trace of things
getting delayed without spamming some real group.

I propose we declare this solved for now and leave the rest of the people
on the list alone. If I can isolate a failure in the future, I'll file a new
ticket.

-Ekr

On Sat, May 10, 2008 at 10:54 AM, Glen <[email-masked]> wrote:
> from=<[email-masked]> to=<[email-masked]> proto=ESMTP
> helo=<romeo.rtfm.com>

---

From: Glen <[email-masked]>
Date: Sat, 10 May 2008 10:59:29 -0700

As you wish!  We're always here, so let me know what else you need.

Glen

---

From: "Eric Rescorla" <[email-masked]>
Date: Sat, 10 May 2008 10:03:35 -0700

On Sat, May 10, 2008 at 9:19 AM, Glen <[email-masked]> wrote:
> Okay, I've put a modification in to stop the check that was failing for you,
> and I'm glad that solved it for the moment.

I'm still getting:

-Ekr

---

From: Marshall Eubanks <[email-masked]>
Date: Sat, 10 May 2008 16:55:55 -0400

> getting delayed without spamming some real group.

There is always the "none" working group, which does (or at least did)  
have a mail list.

Regards
Marshall

---

From: James M Galvin <[email-masked]>
Date: Mon, 12 May 2008 16:42:17 -0400

I've trimmed the cc list dramatically.  You've had your issue 
resolved already but in the interests of conversation I did want to 
comment.

-- On Saturday, May 10, 2008 6:15 AM -0700 Eric Rescorla 
<[email-masked]> wrote regarding Re: [rt.amsl.com #7269] ietf.org 
mail blocking? --

> > While the host may certainly exist, presence in the DNS is
> > commonly used as a weak authoritative existence test.  The
> > assumption is that a process, albeit a weak one, was exercised
> > to approve the presence in the DNS.
> >
> > The obvious counter-argument is that a SPAMMER could own the
> > domain they're using and put anything they want in the DNS.
> > The argument is valid to the extent that SPAMMERS are not
> > taking steps to hide their existence or identity.  While there
> > are many ways to slice the "email pie" to find the bad parts
> > (the SPAMMERS), I think we can at least agree that connection
> Well, I'm not a spammer, so either this assertion is wrong or
> people not representing correct identities is a lousy test for
> people attempting to hide their existence. Take your pick.

I don't really want to pick either one.  Instead, what I do know is 
that for any given SPAM check, it may or may not work in any given 
environment.

So, on the one hand, while you may not be a SPAMMER, you exhibit 
SPAMMER behavior as far as this rule is concerned.  On the other 
hand, perhaps this rule is inappropriate for the IETF because the 
behavior it identifies is common among IETF participants.  In that 
case, the rule should be removed.

Glen has already removed the rule for the IETF server so the 
immediate problem is resolved.

Notwithstanding the principle of being liberal in what you receive, 
I believe it's reasonable to expect a minimum of best practices 
from implementations.  Mitigating SPAM is tough enough and this is 
easy to do.  Of course, this is a case where the "best practices" 
are informally stated at best, which I believe is the real issue.

Although this won't qualify as "best practices", per se, but I do 
believe that the IETF should document completely and exactly what 
it does with respect to security and protection.  Doing this would 
provide a foundation for having this discussion about what is and 
is not a good idea for the IETF.  Note that this is not about 
whether the practice itself is good or bad, since that will vary 
with different environments, but whether the practice is good or 
bad for the IETF.

> >  For those cases, this test is just one mechanism among many
> >  that is helpful in the fight against SPAM.
>
> Huh? Why is this so? Say I do "EHLO mail.ietf.org"? That's a
> perfectly valid domain
> name and it maps to an IP address. It just doesn't happen to be
> mine. This only becomes a useful check when you compare it to the
> address that I'm actually coming from.

You're right.  The HELO check, by itself, just to see if the domain 
name is listed in the DNS is pretty weak but, again, taken all 
together, checking "minimum best practices" is effective.  There's 
a list of about dozen checks on incoming email that the IETF server 
does before deciding to accept a message.  And then there's a dozen 
more before deciding if a message is to be distributed.

Failing certain ones gets you an immediate rejection or, in the 
case of SPAM that has already been accepted for delivery, the 
message gets "dropped."

We can debate whether the minimum in the case of the HELO check is 
"check for a DNS listing" or "check that the forward and reverse 
mappings match".  This is one of those cases where, in my 
experience, different environments tolerate different choices.  The 
IETF does not check that the forward and reverse mappings match, 
only that a forward map exists.  Or, it did until this weekend.

> >> > The IETF does not apply strict connection controls but it
> >> > seems reasonable to me to reject apparently "anonymous"
> >> > messages.
> >>
> >> What makes the message anonymous? I'm advertising
> >> "[email-masked]" in my MAILTO.
> >
> > I'm using "anonymous" to mean that the origin of the connection
> > is not clearly identifying itself.  Yes, it could "lie" to get
> > past this particular check but that's exactly the point.  It's
> > not even trying to "do the right thing".
>
> I don't find this particularly convincing. It's identifying
> itself by IP address.
> Given that that's a lot harder to spoof than domain name, I
> wouldn't use the term anonymous...

To be strict, you were not identifying yourself by IP address.  The 
connection can be identified by its source IP address but that's a 
separate test.  We're talking about the domain name in the HELO.

You were identifying yourself with a FQDN that was not listed in 
the DNS.  Had you wanted to identify yourself with a domain literal 
instead that probably would have worked.

Jim