Subject: problem dealing w/ ietf.org mail servers

From: "'kent'" <[email-masked]>
Date: Wed, 2 Jul 2008 22:47:53 -0700

Hi Rich

I'll cc this to the ietf list, as you suggested.

I've found the problem.  It may or may not be something that ietf want's to
do something about -- I would think they would, since it seems to have global
significance.  But I can fix it from this end. 

Specifically, the problem Dave encountered earlier was that the ietf mail
server was rejecting mail without reverse dns, and since the ietf mail server
and the mipassoc.org/dkim.org/bbiw.net mail servers all had ip6 addresses,
and ip6 is used preferentially, and I hadn't set up reverse dns, they were
dropping all mail.  I fixed that, and things started working. 

The only domains I control that had explicit ipv6 addresses were Dave's
domains.  For example, graybeards.net:

    # host graybeards.net
    graybeards.net has address 72.52.113.69
    graybeards.net has IPv6 address 2001:470:1:76:0:ffff:4834:7145
    graybeards.net mail is handled by 10 mail.graybeards.net.
    # host mail.graybeards.net
    mail.graybeards.net has address 72.52.113.69
    mail.graybeards.net has IPv6 address 2001:470:1:76:0:ffff:4834:7145
    # host 2001:470:1:76:0:ffff:4834:7145
    5.4.1.7.4.3.8.4.f.f.f.f.0.0.0.0.6.7.0.0.1.0.0.0.0.7.4.0.1.0.0.2.ip6.arpa domain name pointer mail.graybeards.net.
    #

Mail now works for this domain.

But, it turns out, the ietf.org mail servers are rejecting mail from other
domains as well.  Here's a log entry for one of your messages:

Jul  2 13:10:23 mail sendmail[31264]: STARTTLS=client, relay=mail.ietf.org., 
    version=TLSv1/SSLv3, verify=FAIL, cipher=DHE-RSA-AES256-SHA, bits=256/256
Jul  2 13:10:29 mail sendmail[31264]: m62Hvfbm011799: to=<[email-masked]>, 
    ctladdr=<[email-masked]> (1023/1023), delay=02:12:32, xdelay=00:00:28, 
    mailer=esmtp, pri=662167, relay=mail.ietf.org. [IPv6:2001:1890:1112:1::20], dsn=4.7.1, 
    stat=Deferred: 450 4.7.1 Client host rejected: cannot find your reverse hostname, [2001:470:1:76:2c0:9fff:fe3e:4009]

Rejecting when you can't find a reverse is, of course, a common anti-spam 
technique. 

However, this last address, 2001:470:1:76:2c0:9fff:fe3e:4009, is not
explicitly configured on the sending server; instead, it is being implicitly
configured through ip6 autoconf stuff:

    eth0      Link encap:Ethernet  HWaddr 00:C0:9F:3E:40:09  
              inet addr:72.52.113.176  Bcast:72.52.113.255  Mask:255.255.255.0
              inet6 addr: fe80::2c0:9fff:fe3e:4009/64 Scope:Link
              inet6 addr: 2001:470:1:76:2c0:9fff:fe3e:4009/64 Scope:Global

The 2 ip6 addresses, the link-local address, and the global address, are
generated from the mac address (you can see the 0x4009 at the end) and
configured autmomatically, merely because ipv6 is enabled on this box by
default, and a global prefix is available.

That is to say, it appears the ietf.org mail server is probably now rejecting
mail from *any* box that is getting a default global ipv6 address, since
those addresses will most likely not be in ip6.arpa.  There may be a whole
lot of boxes in this situation. 

Kent

PS -- I'm not sure this will actually make it to the ietf list :-) ...
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Mark Andrews <[email-masked]>
Date: Thu, 03 Jul 2008 16:12:39 +1000

>     stat=Deferred: 450 4.7.1 Client host rejected: cannot find your reverse h
> ostname, [2001:470:1:76:2c0:9fff:fe3e:4009]
> 

	And has false positives.
 
> lot of boxes in this situation. 

	Well Windows boxes will auto register their main address
	in the DNS so there won't be as many as you think.  It's
	not hard to auto register in the reverse DNS.  TCP is usually
	a strong enough authenticator to add a PTR record.  6to4
	only requires a TCP connection to set up the reverse
	delegation.

	Mark
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Keith Moore <[email-masked]>
Date: Thu, 03 Jul 2008 08:38:40 -0400

surely we in the IETF should be able to do better than to have our mail 
servers filter incoming mail based on completely irrelevant criteria 
like whether a PTR lookup succeeds!

how can we expect the rest of the network to be sane if we can't even 
use reasonable criteria for our spam filtering on our own servers?

(to those who would respond by saying that this is a "common" technique, 
I'd like to cite a sign that I saw many years ago which is totally apropos:

"mediocrity is excellence at pursuing the mean"

and there's no better way to pursue the mean that to do something just 
because it's "common".)

Keith

---

From: Bill Manning <[email-masked]>
Date: Thu, 3 Jul 2008 06:46:55 -0700

you are not the first to report this problem.

-- 
--bill

Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).

---

From: Jeroen Massar <[email-masked]>
Date: Thu, 03 Jul 2008 15:57:53 +0200

[..]
> configured through ip6 autoconf stuff:

Which (autoconfig) you should either not be using on servers, or you 
should be configuring your software properly to select the correct 
outbound address. (I prefer to use the autoconfig one for 'management' 
and using a 'service address' for the service).

SMTP shows that it is perfectly usable for these situations as it nicely 
rejects the message with a proper message automatically telling you on 
how to solve it.

> lot of boxes in this situation. 

Those boxes are not set up correctly thus should not be sending email in 
the first place. For that matter you should actually be 
firewalling+logging port 25 outbound so you can monitor any host in your 
network doing illegal SMTP connects. Spam bots don't use IPv6 yet 
(afaik), but when they are aware how 'open' everything is and especially 
that RBL's don't exist yadda yadda, they might just switch over to that.
Good that the mainstream spamreceivers (gmail/yahoo/etc) don't have IPv6 
yet as that would change that scenario.

Configure your mailservers correctly, it helps you send out mail, and it 
helps avoid others receiving crap from you.

Greets,
  Jeroen

--

For postfix folks:
http://www.postfix.org/IPV6_README.html
8<--------------------------------------------------------
/etc/postfix/main.cf:
     smtp_bind_address6 = 2001:240:587:0:250:56ff:fe89:1
-------------------------------------------------------->8
Other SMTP servers have similar mechanisms.

---

From: John Levine <[email-masked]>
Date: 3 Jul 2008 13:58:30 -0000

>like whether a PTR lookup succeeds!

Spam filtering is sort of like chemotherapy, the difference between
the good and the bad is pretty small, and the trick is to find
measures that will kill the disease without killing the patient.  It's
entirely a matter of statistics, not fundamental design.

I can assure you that in the outside world, the amount of legitimate
mail that comes from no-PTR hosts these days is infinitesimal.  It's
one of the filtering rules with the lowest false positive rates.
Other than temporary glitches like the 6-to-4 one, the only place
where I see problems is from auld pharts like us whose mail systems
have been working just fine since the 1980s, and who out of a weird
sort of principle refuse to make changes to bring them in line with
modern practice, even changes that are compatible with equally ancient
STD documents.

So, yeah, spam stinks, but it's not going away, and arguments that you
shouldn't use a technique today because it didn't work in 1998 don't
cut it.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
"More Wiener schnitzel, please", said Tom, revealingly.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Dave Crocker <[email-masked]>
Date: Thu, 03 Jul 2008 07:07:01 -0700

> you are not the first to report this problem.

1. From what I can tell, the only way to know about the reporting form is to 
have seen it on the Announce list.  I certainly cannot see anything from the 
ietf.org page that is relevant.  I think the page needs some sort of IETF 
network admin link, pointing to such information.

2. I suspect it would be helpful for the page it points to to list open issues. 
  Some sort of tracker.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Keith Moore <[email-masked]>
Date: Thu, 03 Jul 2008 11:50:18 -0400

Jeroen Massar wrote:
> outbound address.
that's a bizarre statement.  the distinction between a client and a 
server is an artificial one.  either autoconfig is useful for all kinds 
of machines, or it's almost useless. 
> (I prefer to use the autoconfig one for 'management' and using a 
> 'service address' for the service).
>
> SMTP shows that it is perfectly usable for these situations as it 
> nicely rejects the message with a proper message automatically telling 
> you on how to solve it.
... and the message almost always goes to someone who isn't in a 
position to fix the problem.
> Those boxes are not set up correctly thus should not be sending email 
> in the first place.
people have strange ideas about what is "correct" setup.

Keith

---

From: Keith Moore <[email-masked]>
Date: Thu, 03 Jul 2008 11:59:20 -0400

John Levine wrote:

Spam filtering is sort of like chemotherapy, the difference between
the good and the bad is pretty small, and the trick is to find
measures that will kill the disease without killing the patient.

the analogy falls apart because in most cases there's no recovery from
a spam filter - if a message it's filtered inappropriately, it's
killed.

It's entirely a matter of statistics, not fundamental design.

strongly disagree.   stats can play a part, but there's no substitute
for well-chosen criteria.  (it would help immensely if spam filter
writers actually understood statistics.)

I can assure you that in the outside world, the amount of legitimate
mail that comes from no-PTR hosts these days is infinitesimal.

in large part that's because poorly chosen spam filters have "trained"
mail senders (legitimate and spammer alike) to set up PTR records.
basically the hoops become meaningless.  and IPv6 is a different enough
case that the old assumptions should not be presumed to be valid.

that's hardly a justification for stupidity.

Keith

---

From: "John Levine" <[email-masked]>
Date: 3 Jul 2008 12:32:30 -0400

> that's hardly a justification for stupidity.

I entirely agree.  Where we evidently don't agree is about what's stupid.

R's,
John

---

From: <[email-masked]>
Date: Thu, 3 Jul 2008 17:36:07 +0100

> that's a bizarre statement.  the distinction between a client 
> and a server is an artificial one.  either autoconfig is 
> useful for all kinds of machines, or it's almost useless. 

You are correct when talking about IP networks in general,
however Jeroen is talking about the public Internet, not
IP networks in general. 

Of course another way to make this less bizarre is to stop
using the word "server" to refer to two different things.
Jeroen is saying that an IPv6 devices that wishes to 
advertise its IPv6 address for the purposes of receiving
SMTP connection requests, should not be configured in
such a way that its IPv6 host ID is randomly assigned.

Of course you could try to dynamically update your reverse
DNS to match the random host IDs but that creates corner
cases and race conditions which can be entirely avoided just
by making the publicly visible IPv6 address a static one.
Jeroen further pointed out that there is no reason for 
an interface, which has been assigned a random host ID, 
to suffer with only one address because IPv6 makes it
straightforward to have multiple addresses on an interface.

BTW, I do agree with your general viewpoint of Internet 
email architecture; it is horribly ugly and broken.

--Michael Dillon

---

From: Keith Moore <[email-masked]>
Date: Thu, 03 Jul 2008 12:52:22 -0400

> I entirely agree.  Where we evidently don't agree is about what's stupid.
in this case, what's stupid is filtering mail based on arbitrary and 
largely undocumented criteria, with little regard for the 
consequences.    for instance, such criteria tend to favor large 
spammers over small legitimate users.

Keith

---

From: Mark Andrews <[email-masked]>
Date: Fri, 04 Jul 2008 07:57:58 +1000

> > explicitly configured on the sending server; instead, it is being impli=
> citly
> Which (autoconfig) you should either not be using on servers, or you=20
> should be configuring your software properly to select the correct=20
> outbound address. (I prefer to use the autoconfig one for 'management'=20

	And what is someone who doesn't have a permanent box with
	a static address to do that wants to use TLS to verify
	that one is actually talking to the remote party you are
	expecting to?

	A mobile machine can register its current addresses in the
	DNS regardless much more easily than it can register its
	reverse PTR records.

	Use the ISP's servers?  I don't trust the ISP's servers to do
	the right job.  I don't trust that there is not a copy of the
	correspondence being made and being sent somewhere else.  I
	have NO idea if they are setup to use TLS or not outbound

	Lack of PTR should NEVER be the SOLE reason for rejecting
	email.  I have not problem with is being a weighting into
	the decision of whether a piece of email is spam or not.
	Just don't make it map to 100%.

> SMTP shows that it is perfectly usable for these situations as it nicely =
> 
> rejects the message with a proper message automatically telling you on=20
> how to solve it.
> 
> > That is to say, it appears the ietf.org mail server is probably now rej=
> ecting
> > mail from *any* box that is getting a default global ipv6 address, sinc=
> e
> > those addresses will most likely not be in ip6.arpa.  There may be a wh=
> ole
> > lot of boxes in this situation.=20
> 
> Those boxes are not set up correctly thus should not be sending email in =
> 
> the first place.

	A PTR is not a requirement for sending email.  The IETF
	should live by it's own dog food and accept email from sites
	without PTR records.
 
> For that matter you should actually be=20
> firewalling+logging port 25 outbound so you can monitor any host in your =
> network doing illegal SMTP connects. Spam bots don't use IPv6 yet=20
> (afaik), but when they are aware how 'open' everything is and especially =
> Good that the mainstream spamreceivers (gmail/yahoo/etc) don't have IPv6 =
> 
> Configure your mailservers correctly, it helps you send out mail, and it =
> 

	If you want to demand PTR records then you need to make it
	a requirement of address allocations that control of the
	reverse DNS entry passes down to the actual user of the
	addresses. 

	Mark

>      smtp_bind_address6 =3D 2001:240:587:0:250:56ff:fe89:1

---

From: Bill Manning <[email-masked]>
Date: Thu, 3 Jul 2008 15:05:24 -0700

> 	DNS regardless much more easily than it can register its

	er... both are registering things in the DNS. manipulation
	of the farward map is occasionally easier than manipulation
	of the reverse map... which i think is what you are trying 
	to say.

	and it is often true that those who manage the forward DNS map
	are -NOT- the same folks that manage the reverse DNS map.

--bill

---

From: "TS Glassey" <[email-masked]>
Date: Thu, 3 Jul 2008 15:31:48 -0800

In fact many ISP's only allow their clients to update the forward maps since 
they don't want to set those blocks of addresses into SWIPPED mode.

T.
----- Original Message ----- 
From: "Bill Manning" <[email-masked]>
To: "Mark Andrews" <[email-masked]>
Cc: "Richard Shockey" <[email-masked]>; "Dave Crocker" 
<[email-masked]>; "Jeroen Massar" <[email-masked]>; <[email-masked]>
Sent: Thursday, July 03, 2008 2:05 PM
Subject: Re: problem dealing w/ ietf.org mail servers

> certainly don't reflect those of any other entity (legal or otherwise).

--------------------------------------------------------------------------------

No virus found in this incoming message.
Checked by AVG.
Version: 8.0.134 / Virus Database: 270.4.4/1532 - Release Date: 7/3/2008 
8:32 AM

---

From: Mark Andrews <[email-masked]>
Date: Fri, 04 Jul 2008 10:47:37 +1000

> they don't want to set those blocks of addresses into SWIPPED mode.

	It's quite possible to allow individual machines to update
	their reverse records without having to delegate the name
	space to the customer.  TCP is a strong enough authenticator
	for this role.

	Mark

---

From: [email-masked]
Date: Thu, 3 Jul 2008 23:22:13 -0700

I think I could have been clearer with my message.  It wasn't intended as
either a criticism of the ietf list management (in fact, I use precisely the
same anti-spam technique) or a request for help with configuration of my
mailservers (I may not be the sharpest knife in the drawer, but usually I can
figure these things out on my own).

Instead, I was presenting what I thought was an interesting example of a 
subtle problem that can come up in ipv6 deployment.  

The mailserver in question uses a default redhat enterprise build (actually
centos).  ipv6 is either enabled by default, or just has a single check box,
with no further information.  The fact that ipv6 is enabled so trivially
carries the implication that just enabling ipv6 won't actually damage
anything. 

Now I know different.  Just enabling ipv6 on an otherwise correctly
configured and functioning ipv4 box *will* cause damage -- it will cause mail
that would have been delivered to not be delivered.  I could be wrong, but
this strikes me as a trap that lots of people could fall into. 

As I mentioned, my servers actually do reject mail if they can't find a 
reverse dns for the senders IP.  Some of those servers use ipv6; in light of all 
this I'm going to have to rethink that decision.  For a server, the 
combination of enabling ipv6 and using this particular anti-spam technique 
may drastically increase the number of false positives -- especially as ipv6 
gets more widely deployed.

Best Regards
Kent

---

From: Jeroen Massar <[email-masked]>
Date: Fri, 04 Jul 2008 12:35:11 +0200

(That draft would basically be a BCP, cc'd to v6ops where this belongs)

[email-masked] wrote:
> I think I could have been clearer with my message.[..]

I think it is a good idea to document common examples of how one could 
setup a datacenter, or at least a small network. One thing to note is 
that people should stop thinking in IPv4 terms. Yes, IPv6 is in effect 
only more bits, but those bits belong to you and you can use them to do 
all kinds of new interesting setups as you are not limited any more to 
what you are doing with respect to address usage.

Generally the ideas for a network I follow are:

  - autoconfig (or if wanted DHCPv6) for hosts (client+server)
    Turn off RFC3041 on all hosts (it is just annoying IMHO :)

  - for servers use the autoconfigged address for 'management' purposes

  - for services, use a /64 per service, or just use one with all
    services. Call these 'service prefixes'.
    Thus DNS could be <pfx>::53/64. Then you can use quagga or similar to
    do OSPF/BGP/whatsuitesyou on the server and announce that it is able
    to serve DNS, just announce the <pfx>::53/64 (or /128 or whatever)
    everything in the network can use <pfx>::53 for DNS resolutions.
    Of course the side-effect is that you can just setup another host and
    do the same trick, then have some scripting on those hosts to check
    if the service is actually working and retract announces when needed.
    Voila a very nice distributed-by-anycast-local-service setup.
    Repeat this trick for any service you want. Remember, if your service
    becomes busy, just add another box, or just move it to another etc.
    Also, if the MAC of the box dies, it is unrelated to the actual
    service and outages will be kept to a minimum. This of course works
    for http-proxies/smtp-servers/imap-servers etc.

    Note that for the service prefix, as it is generally only for serving
    local clients, one could quite well use a ULA prefix, which will
    thus will never change even if changing upstreams or disconnecting
    etc. YMMV on that one though. Note that you just need a route to that
    ULA prefix and can avoid clients having to have a secondary address
    in that range. Benefit for ULA prefix is of course that automatically
    it will be hard for external sites (The Big Bad Internet) to reach
    these services as they don't easily get a working TCP bidirectional
    path to it.

  - Forward/Reverse DNS, I simply register the EUI-64's in DNS,
    hardcoded. One can of course with DHCPv6/(Secure-)DDNS also do it
    dynamically if wanted. If you are a Windows-shop Active Directory
    can also help you out in this area. It depends a bit on what you
    require, how many hosts you have and also how much control you have
    over these hosts.

  - DNS resolving is configured either static (we have the service prefix
    which will most likely never change anyway if lucky) or you could
    simply do it using DHCPv4||v6.

  - Don't forget to properly configure your firewalls ;)

Another note for a lot of people who use a VPN when working from home 
but where the VPN is only IPv4-capable. When you are at home you will 
have a (public) IPv4 address, an IPv6 address and a VPN-IPv4 address, 
but no VPN-IPv6 address, thus most likely the Internet-IPv6 address will 
thus hit the firewall and die off there. Thus if you have 
firewalled@work, AAAA's in the DNS you won't be able to reach them and 
hilarity ensues as this will cause lots of connections delays due to 
most firewalls dropping connections, not rejecting them. Thanks to our 
marvelous IS team here though I found out that ISATAP is a perfect 
solution to this problem as it automatically sets up tunnels locally 
when needed, as the VPN IPv4 is 'local' the tunnel works and you can 
reach resources which would be firewalled when using the global address. 
Which reminds me to quickly write&submit another draft I had in my head 
on that subject.

> carries the implication that just enabling ipv6 won't actually damage

Unfortunately if people just click they will open a lot of things that 
are not needed and can cause issues, for them bot more importantly for 
others. As that means that the box is not properly configured, clearly 
as the 'admin' didn't care, why would anyone then even care to receive 
mail/traffic from them?

> this strikes me as a trap that lots of people could fall into. 

People who make those mistakes are the same people who don't read the 
manual/readme/mustread etc, unfortunately that also means that they will 
never ever read a BCP even if someone wrote one up.

> gets more widely deployed.

As I mentioned, servers/hosts which are not properly set up, are indeed 
just that, not properly set up, as such they don't even deserve my time.

Note also that if you open this loophole that for spammers it becomes 
really easy to start spamming you from any host on the planet, and using 
at least a /48 per IPv4 address and a large chunk of the Teredo /32 to 
choose their source addresses from. Note also that it is quite difficult 
to contact those people in general, because that is what they want, not 
to be contacted.

Thus my summary on this: if they don't care, why should you care? :)

Greets,
  Jeroen

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Fri, 4 Jul 2008 10:46:31 +0200

On 3 jul 2008, at 15.57, Jeroen Massar wrote:

> outbound address. (I prefer to use the autoconfig one for  
> 'management' and using a 'service address' for the service).

What a shame that's not what's in the RFCs..:-)

Best regards,

- kurtis -

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Fri, 4 Jul 2008 12:45:52 +0200

Best regards,

- kurtis -

---

From: John C Klensin <[email-masked]>
Date: Fri, 04 Jul 2008 09:10:26 -0400

--On Friday, 04 July, 2008 10:46 +0200 Kurt Erik Lindqvist
<[email-masked]> wrote:

>>> However, this last address,
>>> 2001:470:1:76:2c0:9fff:fe3e:4009, is not explicitly
>>> configured on the sending server; instead, it is being  
>>> implicitly
>> Which (autoconfig) you should either not be using on servers,
>> or you   should be configuring your software properly to
>> select the correct   outbound address. (I prefer to use the
>> autoconfig one for   'management' and using a 'service
>> address' for the service).
> 
> 

Despite the ":-)", I think there is an important question here.

Does it imply that this is a use case from which we should be
learning... and then fixing the RFCs?  Or that you believe that
the RFCs are correct and Jeroen's analysis is incorrect?   

I hope it doesn't mean "the RFCs ought to govern, even when
reality and experience seem to contradict them".

   john

---

From: Jeroen Massar <[email-masked]>
Date: Fri, 04 Jul 2008 15:21:49 +0200

[..]
> the RFCs are correct and Jeroen's analysis is incorrect?   

I guess/hope he is just teasing ;)

As I privately replied to Kurt already, RFCs are Requests For Comments, 
as such what I am giving is definitely a comment, and the only way to 
solve it for real and to give some guidance is to move this problem to 
v6ops (which I think is the most appropriate WG) and document scenarios 
that guide people on how to possibly configure a network using IPv6.

Of course people could also just get a good book and/or use common 
sense, unfortunately that is not always happening, especially the latter.

> reality and experience seem to contradict them".

See my message to ietf@ + v6ops@ titled:
"Draft on how to correctly configure servers and other hosts (IPv4+IPv6)
  (Was: problem dealing w/ ietf.org mail servers)"

As RFC's can be updated as much as we want and they definitely are not 
final.

Greets,
  Jeroen

---

From: Keith Moore <[email-masked]>
Date: Fri, 04 Jul 2008 10:53:41 -0400

> this strikes me as a trap that lots of people could fall into. 

that's one way to look at it.  another way to look at it is that poorly 
chosen spam filtering criteria *will* cause damage, because conditions 
in the Internet change over time.

of course, IPv6 will often get blamed for the problem because it's 
something that the sender can control, whereas the spam filters are not 
accountable to anyone.

Keith

---

From: [email-masked]
Date: Fri, 4 Jul 2008 09:43:41 -0700

> in the Internet change over time.

Can't disagree with that :-) 

In fact, I've never been very happy with this particular technique for
dealing with spam.  Reverse dns is not required for standards-compliant
delivery of mail, and it is my personal opinion that the ietf in particular
should not be using it as an absolute filtering criteria.  [Also, in my 
experience it hasn't been particularly effective.]

> something that the sender can control, whereas the spam filters are not 

That's a bit of an overstatement -- very frequently spam filters are
accountable to the people receiving the email, and in my experience, most 
people would rather deal with some spam than lose important email.

Kent

---

From: Ned Freed <[email-masked]>
Date: Thu, 03 Jul 2008 10:00:39 -0700 (PDT)

> entirely a matter of statistics, not fundamental design.

And sort of not like it at all. For one thing, the mutation rate in the spam
world is much higher. And that brings us to the real issue here: Whether or not
a given technique, which was very effective indeed at one point, is effective
enough now to continue using.

> mail that comes from no-PTR hosts these days is infinitesimal.

And in my experience the amount of spam coming from such sources, while much
greater, is now distinctly in the minority in terms of all incoming spam. More
specifically, since rather than rejecting mail coming from IPs with no PTR
entry I instead use this as a weighted factor in computing an overall spam
score, I was able to examine today's spam to see to what extent this check is
helping or hurting. Turns out it's doing neither - I could eliminate it
entirely and my false negative rate would not go up by even a single message.
And right now the weight is sufficiently low that it isn't causing any false
positives either.

This defense definitely was very effective once upon a time, but the world has
adapted. In this particular case what seems to have happened is that because of
various PTR record checks a lot of ISPs now unconditionally assign PTR records
to every address, e.g., cpe-76-171-209-109.socal.res.rr.com and
173.sub-75-217-87.myvzw.com were associated with the last two dynamic IPs I've
used. A few years ago it was common to get assigned IP with no PTR records at
all, nowdays much less so.

And this has now led to a new issue: We now have various systems out there that
are now attempting to parse PTR results order to try and figure out the
difference between static business addresses and dynamic residential addresses.
And as you might expect, they often get it wrong.

Now, of course one advantage of this check is that it can be done before you
even accept the message. But the tradeoff then is that this is giving it
infinite weight.

> It's one of the filtering rules with the lowest false positive rates.

> shouldn't use a technique today because it didn't work in 1998 don't

Nor does continuing to use a technique that has outlived it's usefulness. IMO
the utility of this particular check peaked a few years ago and we're now on
the down-slope in terms of utility.

And in the specific case of the IETF, where we want to encourage people to use
our servers to experiment with IPv6 and where there are bound to be a lot of
PTR record issues, I think an absolute block on the basis of no PTR record is
totally inappropriate unless it can be shown to be singularly effective in
dealing with spam and that our spam would increase dramatically without the
rule.  I doubt very much this can be demonstrated.

OTOH, using it as a component in computing an overall spam score may still make
sense, especially if the use of IPv6 could also be factored in.

				Ned

---

From: Dave Crocker <[email-masked]>
Date: Mon, 07 Jul 2008 09:14:02 -0700

> enough now to continue using.

At base, this requires distinguishing between techniques that are heuristics, 
and therefore fickle, versus techniques that can be stable over the long term. 
The former are used to detect bad actors.  The latter can apply for handling 
good actors.

The bad actors are indeed bright, well organized, aggressive and very, very 
adaptable. Any use of heuristics must therefore be extremely agile.  The 
diligence and expertise this requires is onerous.  Typically, only the largest 
services can afford to do this in-house.

By contrast, a trust overlay, based on prior assessment of good actors, ought to 
be much lower overhead and much more stable.  However we have less experience 
with this side of the equation.

> adapted. 

Exactly.

> Nor does continuing to use a technique that has outlived it's usefulness. 

Exactly.

> totally inappropriate 

+1

d/
-- 

   Dave Crocker

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 7 Jul 2008 18:18:43 +0200

> should be configuring your software properly to select the correct  

Is it the IETF's job to tell people how to run their networks?

In my opinion, stateless autoconfig is a perfectly acceptable way to  
configure servers.

> nicely rejects the message with a proper message automatically  
> telling you on how to solve it.

I ran into the issue with the non-existant IPv6 reverse mapping twice.  
I would prefered to have solved this by getting proper delegation from  
my ISP, but I haven't been able to get this done for years.

Anyway, the first time I opened a ticket they told me it was fixed.  
Then the problem returned and they told me I was put on a whitelist.  
As this thread indicates, that's hardly a solution, especially since I  
was unable to get Sendmail to NOT use IPv6 without completely  
disabling the protocol on my system, making it completely impossible  
for me to deliver mail to the IETF servers. (Serves me right for  
running Sendmail I guess.)

> Those boxes are not set up correctly thus should not be sending  
> email in the first place. For that matter you should actually be  
> firewalling+logging port 25 outbound so you can monitor any host in  
> your network doing illegal SMTP connects.

In my opinion, filtering at layer 4 because a layer 7 protocol is  
broken is a bad idea.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Francis Dupont <[email-masked]>
Date: Mon, 07 Jul 2008 18:28:50 +0200

In your previous mail you wrote:

   Specifically, the problem Dave encountered earlier was that the ietf mail
   server was rejecting mail without reverse dns, and since the ietf mail
   server and the mipassoc.org/dkim.org/bbiw.net mail servers all had ip6
   addresses, and ip6 is used preferentially, and I hadn't set up reverse dns,
   they were dropping all mail.  I fixed that, and things started working. 
   
=> I had the same problem (IPv6, no reverse, dropped messages),
I asked the IETF postmaster to fix it and it was (quickly, thanks) fixed.
 But I still believe this is a bad idea to check IPv6 reverse DNS,
I reverved this topics for the plenary at Dublin but as you open it...

=> according to Glen via RT (RT is a well known bug ticket system):
 "This check is in place at the direction of the IETF community, and has
  been discussed and debated at length."
so as the IETF community voice is this list IMHO it is appropriate
(until some authority delegates the issue to the v6ops WG?).

Thanks

[email-masked]
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Keith Moore <[email-masked]>
Date: Mon, 07 Jul 2008 12:54:38 -0400

>   been discussed and debated at length."

I don't recall the Last Call on that question, nor even the I-D.

seems like this calls into question the competence of the people running 
IETF's servers.  they really ought to know better than to accept random 
rumors as technical advice.

Keith

---

From: SM <[email-masked]>
Date: Mon, 07 Jul 2008 11:34:06 -0700

>   been discussed and debated at length."

I don't recall seeing any community debate before this check was 
implemented.  Can someone point me to that thread?

Regards,
-sm

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 8 Jul 2008 19:21:48 +0200

(Apologies for the late reply)

> reality and experience seem to contradict them".

So, from my POV there are a few issues here.

1) I do understand where the current "last 64 bits are EUId" comes from.

2) Someone (I think it was Keith Moore) said that if the scheme  
doesn't work for servers AND hosts (i.e no difference) it's a bad  
scheme. I sort of agree with that, but the reason it doesn't work for  
servers is simply lack of management tools, and the fact that a lot of  
protocols / implementations tend to use addresses rather than names.

2) In operational reality, I have learnt that EUI64 for workstations  
and similar hosts in combination with non EUI64 numbers for servers  
works quite well and is how I work with deployments. And I have a lot  
of respect for operational experience and reality. So yes, I think  
this is worth considering. Do I believe such a rule can be written  
clearly and get IETF consensus....that is a different question.

Best regards,

- kurtis -

---

From: Keith Moore <[email-masked]>
Date: Tue, 08 Jul 2008 14:41:32 -0400

> 2) Someone (I think it was Keith Moore) said that if the scheme doesn't 
> work for servers AND hosts (i.e no difference) it's a bad scheme. I sort 
> of agree with that, but the reason it doesn't work for servers is simply 
> lack of management tools, and the fact that a lot of protocols / 
> implementations tend to use addresses rather than names.

I disagree that it doesn't work for servers.   (Or it would be better to 
say that I'd like to know why you think it doesn't work for servers.)

Keith

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Thu, 10 Jul 2008 13:06:13 +0200

On 8 jul 2008, at 20.41, Keith Moore wrote:

>> scheme. I sort of agree with that, but the reason it doesn't work  
>> for servers is simply lack of management tools, and the fact that a  
>> lot of protocols / implementations tend to use addresses rather  
>> than names.
>
> I disagree that it doesn't work for servers.   (Or it would be  
> better to say that I'd like to know why you think it doesn't work  
> for servers.)

Well, when I change that broken NIC in my server, it will receive a  
new address that needs to be reflected in the DNS. Sure, that can be  
automated or updated, but in general you want some stability in the  
server address. I have actually run my personal mail-server on an  
EUI-64 address for quite some time. The problem when the NIC failed  
was that it took until the cache expiry for some servers to contact it  
again. Like ietf.org.

There are other addresses, like router interfaces where EUI64  
addresses are simply a nightmare, as when you are doing network  
troubleshooting you need to keep 128 bits in HEX in memory - which I  
am too stupid to be able to...an alternative would be to have routing  
tables do DNS lookups for NEXT_HOPS - it's just a lot of DNS lookups....

Best regards,

- kurtis -

---

From: Jeroen Massar <[email-masked]>
Date: Thu, 10 Jul 2008 22:07:37 +0200

[..]
>> I disagree that it doesn't work for servers.   (Or it would be better 
>> to say that I'd like to know why you think it doesn't work for servers.)

People have personal opinions, one likes this, the other likes that, 
maybe it works for you, maybe it works different for me.

> Well, when I change that broken NIC in my server, it will receive a new 
> address that needs to be reflected in the DNS.

Which is why EUI-64 is a great method on combination with RA to do 
autoconfiguration, but if somebody (for whatever reason they have) want 
to use those 64bits differently (eg using DHCP or static config) they 
should definitely do so, it is their network after all, and there is no 
meaning in those bits.

EUI-64/RA is just to make some cases (the dental office one for 
instance) really simply, but it is not a solution for everything else.
Pick and use what is useful...

BTW: Most OS's allow overriding of the MAC address, next to of course 
just configing an "automatic EUI-64 address" as a static one on an 
interface ;) Your network, your rules, your problem if you peep it up.

Greets,
  Jeroen