Subject: Re: several messages

From: der Mouse <[email-masked]>
Date: Tue, 11 Nov 2008 18:49:20 -0500 (EST)

>> The Spamhaus XBL and Spamhaus PBL are pretty useful in denying
>> connections from botnets. You should try them - in the arsenal of
>> spam-fighting tools, they are the probably most effective ones.
> I've heard this about Spamhaus' lists.  One wonders how it is
> possible they are so useful and effective.

It is a good question.  I don't know the answer - but I don't have to
understand _how_ they manage it to know _that_ they manage it.

> Sometimes Vixie denies involvement with SORBS, sometimes he is
> willing to talk "1x1" about SORBS business model.  How can one trust
> such activities by the top people?

By trusting the people, of course.

Your example is pretty totally bogus, though.  I have no involvement at
all with, say, Walmart, or L. L. Bean, but I can blather all evening
about their business models; does that mean I'm untrustworthy?

>> Wnat DNSBLs do is mitigate the damage so that we have at least
>> middling-usable email while solutions evolve at the social level.
> I agree.  But there are technical reasons that they can't possibly
> keep up, too.

They have been so far.  When reality disagrees with logical deductions,
the thing to do is look for the incorrect assumption or the flaw in the
logic, not to assert that reality is wrong.

>> Using such a list puts a substantial crimp in direct-to-MX spamming.
> That is an interesting euphemism for intentional collateral damage.

"Eupehmism" is not an appropriate word here, I think.  I was not
attempting to sugar-coat something unpleasant.  I was describing a
desirable effect (stopping direct-to-MX spam); that the same thing also
has an undesirable effect (stopping direct-to-MX ham) doesn't make
discussing the desirable effect euphemistic.

Direct-to-MX ham sending is, like open relays, one of the casualties of
the net's getting infested with abusers.  I don't like it, but so what?

>> There aren't many addresses, as a fraction of the Internet, that are
>> statically assigned and send spam.  But the fraction is definitely
>> nonzero, and they tend to send a lot.  DNSBLs work very well indeed
>> against those.
> I'm sure they do.  But those are typically CAN-SPAM compliant
> emailers, and one doesn't need to use a DNSBL for that.

Need to?  I don't know; where's the boundary between need and want?  I
certainly want to, in the sense that it is the lightest-load way I've
found to reject the resulting spam, CAN-SPAM compliant or not.  (Why
the emphasis on CAN-SPAM, by the way?  Surely you don't think only the
USA matters?)

> And even those that weren't burned, surely know better now than to
> trust DNSBLs.

I trust DNSBLs as a class about as much as I trust people as a class,
and I trust DNSBLs individually about as much as I trust people
individually.  That is to say, a few are utterly wonderful, a few are
utterly horrible, and there's a whole spectrum in between.

> Indeed, the numbers of mail bounced when these blacklists shut is a
> better indicator of how many people actually used them.  There was a
> howl on Nanog, but no global disaster.  That should tell you
> something.

Yes; it tells me that comparatively few people used DNSBLs which are
badly run enough to have shut down disruptively.  It tells me nothing
at all about how many people use DNSBLs which are not that badly run.

> What multi-million dollar ISP really wants to trust its email service
> to some guy on a DSL line running a DNSBL out of his basement?

Irrelevant.  The existence of amateurishly-run DNSBLs does not imply
the nonexistence of well-run ones.  It _does_ mean that someone to whom
email is important had better do due diligence in selecting DNSBLs -
just as someone to whom a car is important had better do due diligence
in selecting a mechanic, or someone to whom good clothes are important
had better do due diligence in selecting a tailor....

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 12 Nov 2008 11:15:30 -0800

Hi -

> From: "der Mouse" <[email-masked]>
> To: <[email-masked]>; <[email-masked]>
> Sent: Tuesday, November 11, 2008 3:49 PM
> Subject: Re: several messages
...
> had better do due diligence in selecting a tailor....
...

Agreed, but if those analogies are correct, they also undermine the argument.
Neither the email sender nor the recipient (the ones to whom email is most
important) typically have any voice whatsoever in the selection of the DNSBL.

Randy

---

From: David Romerstein <[email-masked]>
Date: Wed, 12 Nov 2008 11:18:24 -0800 (PST)

> important) typically have any voice whatsoever in the selection of the DNSBL.

End recipients *absolutely* have a voice in the DNSbl selection process. 
They have the option of voting with their feet if their ISP chooses a 
DNSbl that negatively impacts them.

-- D

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 12 Nov 2008 11:33:46 -0800

Hi -

> From: "David Romerstein" <[email-masked]>
> To: <[email-masked]>
> Sent: Wednesday, November 12, 2008 11:18 AM
...

Huh?  Concrete, real example:  I send a message to an IETF mailing list.
A list subscriber's ISP rejects the forwarded message.  IETF's mailman
drops the subscriber, because this has been happened multiple times.
I can't notify the subscriber, because their ISP also rejects my email.
My ISP is irrelevant to the scenario, and the (now former) list subscriber
doesn't even know this has happened, or why.

Another real, concrete example: some (but not all) messages sent via my
employer were tossed because one of my employer's mail servers was
listed on a blacklist.  As an employee, I had no alternatives for sending
mail - company policy precluded the use of "webmail" alternatives via
company infrastructure.

Randy

---

From: "Chris Lewis" <[email-masked]>
Date: Wed, 12 Nov 2008 14:38:57 -0500

> DNSbl that negatively impacts them.

Or as in the case with a non-ISP (eg: a corporate environment like us),
they _are_ the end recipients.  The liability for missed email, for
example, is entirely the corporation's.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: David Romerstein <[email-masked]>
Date: Wed, 12 Nov 2008 11:43:24 -0800 (PST)

> I can't notify the subscriber, because their ISP also rejects my email.

If they don't notice the dropped subscription, I'd say they're not 
negatively impacted.

> doesn't even know this has happened, or why.

And, if they contact IETF to find out why the subscription was dropped, 
IETF should have a mechanism (such as an email address external to their 
blocked IP) by which they can communicate with such people and remediate 
the issue.

> mail - company policy precluded the use of "webmail" alternatives via

You're not the end recipient. I assume you have out-of-band methods of 
contacting customers that were blocking you (such as, say, a phone 
number). Yep, more work for you as a sender; still not impacting on the 
end recipient.

-- D

---

From: "Chris Lewis" <[email-masked]>
Date: Wed, 12 Nov 2008 15:54:46 -0500

> doesn't even know this has happened, or why.

That sort of thing is rarely due to a DNSBL issue.  DNSBLs are usually
on peers.  For your email to have been blocked via both the IETF and
directly from you, it usually would have had to have been both the IETF
and you that was blocked by the list subscriber's ISP.  Which one would
hope would be a rare circumstance...

It was probably a content filter.

We whitelist many mailing lists and forwarders by IP, especially those
that talk about spam....  Unless they leak LOTS of real spam (we're
talking > 99% spam).  And some do.

> mail - company policy precluded the use of "webmail" alternatives via

The duration of that event should have been short (and usually is).  And
companies do have means to deal with such eventualities.

For example, in a situation like that, many people can cope by sending
such critical email by non-company infrastructure.  Or relax the rules
for the duration of the problem.

Once or twice we've been inadvertently hit by a similar blacklisting.
They've always been resolved very quickly with little harm done.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: <[email-masked]>
Date: Wed, 12 Nov 2008 21:07:05 -0000

> A list subscriber's ISP rejects the forwarded message.  
> IETF's mailman drops the subscriber, because this has been 
> happened multiple times.
> My ISP is irrelevant to the scenario, and the (now former) 
> list subscriber doesn't even know this has happened, or why.
> 
> Another real, concrete example: some (but not all) messages 
> sent via my employer were tossed because one of my employer's 
> mail servers was listed on a blacklist.  As an employee, I 
> had no alternatives for sending mail - company policy 
> precluded the use of "webmail" alternatives via company 
> infrastructure.

This is the type of thing which should be discussed in a much
longer Security Considerations section, even if it is only
an informational RFC. A DNSBL sits in the middle of an
end-to-end email transaction, and there is a danger of this
type of mysterious man-in-the-middle effect. The issues
surrounding this should be openly disclosed in the RFC.
Many RFCs don't need more than a cursory Security Considerations
section, but this one does, partly because of its impact on
end-to-end email transactions, and partly because of its
overloading different meanings onto the DNS protocol.

If reputation systems are going to be an integral part
of the future Internet email service, then this existing
DNSBL needs to be properly documented, and it would be
fruitful to have a WG take on the task of designing something
that looks less like a temporary band-aid solution.

--Michael Dillon

---

From: Matthias Leisi <[email-masked]>
Date: Wed, 12 Nov 2008 22:55:00 +0100

> end-to-end email transaction, and there is a danger of this

A fine, but important distinction: DNSxLs do not sit in the middle. They
provide data to the receiving mail system about the sending mail system,
which is then pretty much free to decide what to do with this data.

> of the future Internet email service, then this existing

"going to be"? They already are. Since about 10 or so years.

-- Matthias

---

From: David Morris <[email-masked]>
Date: Wed, 12 Nov 2008 20:08:55 -0800 (PST)

> DNSbl that negatively impacts them.

That assertion reflects a lack of thought about the process. The user with
the ISP using the poorly administered DNSBL is the target of my email and
may not know about the missing mail or may be an organization who doesn't
care. Their support staff is happy about the amount of real spam blocked
and will easily down play the frustration of their users re. false
positives. It is my observation that even within companies producing
anti-spam products, it is difficult to get effective reporting of FPs and
FNs. The majority of users of large ISPs like AOL, MSN, Earthlink,
NetZero, etc. just swear at their computers and do nothing.

Just because the DNSBL does exactly what it says it will, doesn't mean
that the mail administrators configuring use of that DNSBL really
understands the implications. Sounds good to exclude mail from dynamic IPs
... the flaw is in the detection of dynamic IPs.

Given that the well known DNSBL causing me grief totally ignores my
requests for removal, I have no reason to blame my ISP for the situation
nor have I any reason to believe my ISP would have any more luck. So why
should I take all the steps to reprovision my network with new public IPs
from another ISP with no assurance the problem won't repeat.

One email target ISP, readily white listed my mail server's IP. They
admitted they knew that the DNSBL they referenced to bounce my mail was
poorly administered but still used it. The contractor I was attempting to
email would hardly see an ocassional issue as reason to change is
published email provider.

In the end, walking isn't a viable alternative.

Someone else mentioned that due dilligence was needed on the part of folks
providing email spam filtering based on specific DNSBLs. Exactly were does
one find reliable rating of such services? How do you determine what the
trash to value ratio is in a specific DNSBL's database?

In my experience, the damage to email services are more in the area of
administration and policy of the DNSBL than at the protocol level.

Documenting the current protocol as Informational seems sufficient. Put
the IETF reputation behind BCPs which describe how well run DNSBLs should
be administered. Perhaps define how a mail administrator might evaluate a
DNSBL's performance.

If interest warrant, follow the suggestion from Kieth (and others?) to
form a working group to evaluate protocol alternatives and design a
possibly improved protocol.

David Morris

---

From: "Al Iverson" <[email-masked]>
Date: Wed, 12 Nov 2008 23:25:28 -0500

On Wed, Nov 12, 2008 at 11:08 PM, David Morris <[email-masked]> wrote:
> care.

No, but working for an ESP myself, I can tell you that the end users
often do complain about non-receipt of email, and I am sure I am not
the only person who has nudged a user to switch ISPs (or webmails)
because of a poor choice of spam filtering and deafness of their
previous ISP. It does happen.

It's true that Joe User doesn't know about the DNSBL's involvement,
and may not even know what a DNSBL is. But, being the guy at this ESP
who works with ISPs and blacklists, and there have to be a lot more
people like me out there. Both fixing things to prevent or address
listings from DNSBLs that can be worked with, and by helping ISPs to
understand when a stupid blacklist should be called a stupid blacklist
and ignored.

(Just for the record, the only instances in which my point of view
actually aligns with Dean Anderson's point of view are purely
coincidental. Call it the stopped clock principle.)

> In the end, walking isn't a viable alternative.

Because it's so hard to open a Gmail account? I think your thinking
here is about two generations out of date. Back in 1995 when we each
had our one dialup account, and webmail was much less common and
acceptable, your point would have been more valid.

Regards,
Al Iverson

-- 
Al Iverson on Spam and Deliverability, see http://www.spamresource.com
News, stats, info, and commentary on blacklists: http://www.dnsbl.com
My personal website: http://www.aliverson.com   --   Chicago, IL, USA
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: David Morris <[email-masked]>
Date: Wed, 12 Nov 2008 20:37:08 -0800 (PST)

> acceptable, your point would have been more valid.

C'mon ... my example contractor has printed collateral, web pages, etc.
all with his email address. Changing an email address is non-trivial for
folks who don't have any need to register their own domain name. Even
those who have a web serving domain often have no business need for
email.

I could use my yahoo or gmail account to send him email, but then I have
to deal with watching said account for responses. At best a frustrating
waste of time.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: "Al Iverson" <[email-masked]>
Date: Wed, 12 Nov 2008 23:46:39 -0500

> those who have a web serving domain often have no business need for

The professional who has printed their AOL.com email address on their
business card has problems that are far greater than, and not unique
to, an ISP's use of DNSBLs.

Regards,
Al Iverson

---

From: David Morris <[email-masked]>
Date: Wed, 12 Nov 2008 21:02:17 -0800 (PST)

> to, an ISP's use of DNSBLs.

I never said they used aol.com ... only that it was a major ISP. Both that
ISP and aol *HAVE* worked to deal with issues I've had. Other ISPs have
not. It was still a waste of my time.

My point is that it is difficult to change email addresses because there
are lots of references which have value. Business cards are one example.
All other business printed materials are another. Every customer's mail
folders are another.

Simply walking from an ISP isn't an easy choice. This is particularily
true for folks for home computer technology is simply a tool they use to
communicate. This general issue is well enough understood that the FCC
forced phone companies and cellular carriers to provide number portability
to insure folks with an investment in their phone number could take
advantage of competition.

Dave Morris

---

From: John Levine <[email-masked]>
Date: 13 Nov 2008 11:23:02 -0000

>requests for removal, ...

I'd be interested in knowing what DNSBL it is.  Spamhaus PBL?
MAPS/Trend DUL?  SORBS?  Something else?

All the anonymous denunciations here are getting a bit tedious.

R's,
John

---

From: Jim Hill <[email-masked]>
Date: Thu, 13 Nov 2008 12:34:10 +0000

John Levine in <[email-masked]>:
> David Morris in <[email-masked]>:
>
> I'd be interested in knowing what DNSBL it is.

> > Received: from email.xpasc.com (email.xpasc.com [65.85.17.142])
> > 	by core3.amsl.com (Postfix) with ESMTP id 2CAE63A6782
> > 	for <[email-masked]>; Wed, 12 Nov 2008 20:09:01 -0800 (PST)

| dig any 142.17.85.65.dnsbl.sorbs.net +short
| 127.0.0.10
| "Dynamic IP Addresses See: http://www.sorbs.net/lookup.shtml?65.85.17.142"

Certainly looks to be listed incorrectly ... 

| dig -x 65.85.17.142 +short
| email.xpasc.com.

| dig a email.xpasc.com +short
| 65.85.17.142

| whois -h whois.geektools.com 65.85.17.142
| OrgName:    MegaPath Networks Inc.
| ReferralServer: rwhois://rwhois.megapath.net:4321/

| nc rwhois.megapath.net 4321
| %rwhois V-1.5:003eff:00 siberia.megapath.net
| 65.85.17.142
| network:ID:NET-65.85.17.128/28
| network:Organization;I:BARILI SYSTEMS LIMITED

| whois -h whois.geektools.com xpasc.com
| Administrative Contact, Technical Contact:
| Morris, David W
| Barili Systems Limited

That seems to satisfy all the requirements for removal listed at
<http://www.us.sorbs.net/faq/dul.shtml>
--

---

From: John C Klensin <[email-masked]>
Date: Thu, 13 Nov 2008 08:47:35 -0500

--On Wednesday, 12 November, 2008 23:46 -0500 Al Iverson
<[email-masked]> wrote:

>...
> The professional who has printed their AOL.com email address
> on their business card has problems that are far greater than,
> and not unique to, an ISP's use of DNSBLs.

And yet, Al, it is fairly regularly done.  And yahoo.com
addresses are even more common -- a usage that, at least at one
time, Yahoo actively encouraged for those who were maintaining
stores there.  I also see mac.com and gmail.com email addresses
on business cards fairly regularly.

Now, if people ask me for advice, I tell them that they are
better off with their own domains and with associated Whois info
that points directly to their businesses (no anonymous or hidden
registration stuff).  But only a tiny percentage ask me.

Assuming one of these professional has decided, even by default,
to do that, where is it written that they have problems
sufficiently severe that you get to decide that they really are
not entitled to reliable email?

You should also be aware, in case you are not, that in many
parts of the world (and even the US) the choice of ISPs for a
residential customer is essentially limited to one.  And that
ISP, based on how they have interpreted advice from the antispam
community, has tried to block outbound SMTP connections that go
anywhere but to their servers.

     john

---

From: "Al Iverson" <[email-masked]>
Date: Thu, 13 Nov 2008 09:42:45 -0500

> on business cards fairly regularly.

John, I'm sorry you misunderstand. I was already well aware that some
people use an ISP email address on printed materials. Maybe they paint
it on their van down by the river. Just like with a phone number.

That doesn't negate the fact that there is ample evidence that
recipients will jump ship on an ISP when they can't get desired mail.
Again, working for an ESP, this is a scenario that I deal with
regularly.

Both scenarios exist, clearly. I don't agree that it's hard to change
ISPs (or set up a second mailbox to route around an inbound delivery
issue), but I grant that it is non-trivial for many.

Ultimately, though, I need a better understand here. Not getting it
from what's been said so far. What's the point?

If the point is that DNSBLs should be more accountable, and we should
work toward a world where spam filtering usage, usage of DNSBLs, can
be configured on a per-user basis, and a user has an easy method of
opting in or opting out, then I'm in full agreement.

But that's not where the world is today, and it's unreasonable to
expect it to be written into a specification that will then be
ignored.

If that isn't your point, then I must humbly admit that I don't
understand and I await further insight.

Regards,
Al

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 13 Nov 2008 06:43:17 -0800

This is a somewhat silly discussion, pretty much the ONLY real reason to use your own domain rather than a gmail or aol or whatever is precisely the fact that switching costs are high.
 
And the real problem is not gmail.com but comcast.net. If access to the email address requires continuation of an ISP service the switching cost issue bcomes a very real problem. Even more so if the ISP decides to rename itself - as mine has three times.

________________________________

From: [email-masked] on behalf of David Morris
Sent: Thu 11/13/2008 12:02 AM
To: Al Iverson
Cc: [email-masked]
Subject: Re: several messages

Dave Morris

---

From: "Matthias Leisi" <[email-masked]>
Date: Thu, 13 Nov 2008 16:07:26 +0100 (CET)

> | "Dynamic IP Addresses See:
> http://www.sorbs.net/lookup.shtml?65.85.17.142"
>

>From time to time, I stumble upon an incorrect SORBS DUL entry when
editing dnswl.org entries. A short ticket later, things are usually fixed.

-- Matthias

---

From: "Al Iverson" <[email-masked]>
Date: Thu, 13 Nov 2008 10:40:59 -0500

> All the anonymous denunciations here are getting a bit tedious.

I think anonymous may be a bit better in this context, because
otherwise the conversation degenerates into an argument about some
particular DNSBL, instead of a discussion about DNSBLs in general.

I think a lot of us had a pretty good idea which DNSBL is usually the
one in question when people are complaining....

Al

---

From: Anthony Purcell <[email-masked]>
Date: Thu, 13 Nov 2008 10:55:33 -0500

There is no doubt that email addresses are indeed sticky for most people.
However as someone who works for a mid to large ISP, I can say with
confidence that using 'reputable' DNSBL's save money for the ISP and the
customer as well.

To give an example; previous to our Spamhaus deployment we were processing
over 90M msg per day. After deploying SBL alone that dropped to 10M! This
resulted in not having to buy hundreds of servers and terabytes of disk. If
we had not implemented DNSBLs we would have to raise our costs to the
subscriber to cover the capital expenditure.

Our FP complaints from our subscribers was less than 10 calls in the first
six months. After modifying our DSN's to provide clear language to senders
why we did not accept their message, and giving them a link to resolve the
issue on their own, the complaints from customers disappeared.

So yes, you will always have someone that will be affected. It is my belief
(solely) that mail system managers need to take responsibility for what
flows through their systems. If your users are not doing their due
diligence to keep their PCs from becoming zombies, you as the system
manager need to protect your systems, so you can ensure that everyone can
use them. 

My $.02

Regards,
Anthony

On Thu, 13 Nov 2008 06:43:17 -0800, "Hallam-Baker, Phillip"
<[email-masked]> wrote:
> This is a somewhat silly discussion, pretty much the ONLY real reason to
> use your own domain rather than a gmail or aol or whatever is precisely
the
> fact that switching costs are high.
>  
> And the real problem is not gmail.com but comcast.net. If access to the
> email address requires continuation of an ISP service the switching cost
> issue bcomes a very real problem. Even more so if the ISP decides to
rename
> itself - as mine has three times.
>  
>

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 13 Nov 2008 08:18:01 -0800

> one in question when people are complaining....

The difficulty is that the current line of argument is that because some DNSBLs 
are operated badly, DNSBLs are bad.

For any interesting capability, there will always be some bad actors using it. 
So the argument that, therefore, the capability is unworthy of standardization 
is problematic.

d/

-- 

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

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 13 Nov 2008 11:38:33 -0500

On Thu, Nov 13, 2008 at 08:18:01AM -0800, Dave CROCKER wrote:
> The difficulty is that the current line of argument is that because some 
> DNSBLs are operated badly, DNSBLs are bad.

I think that's not quite fair.  My impression is that there is more
than one line of argument.  Here are some different ones that I have
observed in this discussion, some of which seem never to be getting
answers.  (Or, sometimes, they seem to be getting answers that are
counter-arguments the the first.  I believe philosophers would call
those examples of the straw person fallacy.)

1.  Some DNSBLs are bad, therefore all DNSBLs are bad.  (The one you
note, and which is obviously bogus.)

2.  DNSBLs are in themselves bad, because there is no way to guarantee
that they won't contain false positives; they are nevertheless
possibly useful, but the trade-offs are inadequeately described in the
current document.

3.  DNSBLs are not in themselves bad, but the implementation of them
as described in the current draft (which does describe the current
state of the art in DNSBLs) _is_ bad.  The current behaviour and the
desirable behaviour ought to be separated, and one described while the
other is standardized.

There are probably other positions I haven't covered here.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: David Romerstein <[email-masked]>
Date: Thu, 13 Nov 2008 09:09:19 -0800 (PST)

> <http://www.us.sorbs.net/faq/dul.shtml>

I believe that it's listed 'correctly', per that FAQ, for one reason:

[romer@toro mail]$ dig 142.17.85.65.in-addr.arpa

;; QUESTION SECTION:
;142.17.85.65.in-addr.arpa.     IN      A

;; ANSWER SECTION:
142.17.85.65.in-addr.arpa. 86265 IN     CNAME   email.xpasc.com.

CNAME, not PTR. SORBS *appears* to want PTRs (with appropriate TTLs).

-- D

---

From: Jim Hill <[email-masked]>
Date: Thu, 13 Nov 2008 17:42:18 +0000

David Romerstein in
> CNAME, not PTR. SORBS *appears* to want PTRs (with appropriate TTLs).

There is a delegated ptr-record ... 

| dig ptr 142.17.85.65.in-addr.arpa
| 
| ;; ANSWER SECTION:
| 142.17.85.65.in-addr.arpa. 59754 IN     CNAME   email.xpasc.com.
| email.xpasc.com.        59754   IN      PTR     email.xpasc.com.

The ttl seems to be ok as well (ignore the above from my cache).
--

---

From: "Chris Lewis" <[email-masked]>
Date: Thu, 13 Nov 2008 12:53:31 -0500

> note, and which is obviously bogus.)

Obviously.

> possibly useful, but the trade-offs are inadequeately described in the

If all that's missing is a few sentences in the Security Considerations
section, I'm sure that we can get somewhere with that, on the other
hand, discussion of those types of tradeoffs probably don't belong in
this draft, but a BCP.

> desirable behaviour ought to be separated, and one described while the

Behaviour of DNSBL != information transfer protocol.  The document at
hand only describes the protocol, and should only describe the protocol,
and the security considerations should be on the protocol, not the
behaviour.  "Behaviour" is better described in another document.  Like
the BCP I'm supposed to finish the .05 revision on ASAP.

[If I can stop following this thread maybe I'll get it finished.]
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: John C Klensin <[email-masked]>
Date: Thu, 13 Nov 2008 12:54:34 -0500

--On Thursday, 13 November, 2008 08:18 -0800 Dave CROCKER
<[email-masked]> wrote:

>> I think a lot of us had a pretty good idea which DNSBL is
>> usually the one in question when people are complaining....
> 
> 
> The difficulty is that the current line of argument is that
> because some DNSBLs are operated badly, DNSBLs are bad.
> 
> For any interesting capability, there will always be some bad
> actors using it. So the argument that, therefore, the
> capability is unworthy of standardization is problematic.

No, Dave, the argument is that there is no established standard
(sic) of practice that differentiates between badly-operated
DNSBLs and well-operated ones and between appropriate and
inappropriate applications of those lists.  Although perhaps I'm
wrong, I assume that no one would make a serious claim that the
use or non-use of particular data formats (i.e., the document in
question) would be very significant in making that
determination. 

If there were a BCP on the table that would permit us to talk
about DNSRBLs that conform and those that don't, rather than
about subjective opinions of "behaving badly", we would, IMO, be
having a rather different discussion.

If we were talking about putting together a WG here, I believe
that the community would insist on such a BCP as its first
output.  That would give the community an opportunity to have a
serious and focused discussion about criteria for good behavior.
Perhaps this topic is so emotional that such a discussion would
be impossible, but at least there would be hope.  

However, if I can summarize the one thing that people with a
_very_ broad range of opinions that conclude in "don't
standardize this document now" seem to have in common, it is an
objection to standardization of any of this without clear and
documented agreements about acceptable practices and careful
documentation about the problems and risks that can occur when
those practices are not followed (or even if they are).

IMO, that generic objection is well within IETF norms.  YMMD, of
course.

   john

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 13 Nov 2008 09:57:24 -0800

Andrew Sullivan wrote:
> than one line of argument. 

Andrew,

Yeah, I should have qualified what I meant:  I focused on the anecdotal and ad 
hominem (ie, personal) line of argument because of its core philosophical and 
methodological weaknesses and lack of technical basis.

is  being taken seriously and I don't understand why.

>   Here are some different ones that I have
> answers.

I'm planning to carefully review all the postings and try to summarize them with 
considerably more diligence than my previous posting.  To that end, it could 
help quite a bit to see what specific questions you see as needing answering by 
the proponents of the specification.

I should note that I've posted a number of follow-up questions to critics and 
they have mostly been ignored or dismissed.

In stark contrast, the recent posting by John Klensin and then yours and Olaf's 
are clearly based on core principles.  That makes it possible to have 
constructive debates about facts, architecture and operations.

> 1.  Some DNSBLs are bad, therefore all DNSBLs are bad.
> that they won't contain false positives;
> state of the art in DNSBLs) _is_ bad. 

Good summary of critics' concerns, I think.  Thanks.

If anyone believes there are other perspectives that should be listed, please 
say so.

d/

-- 

   Dave Crocker

---

From: Tony Finch <[email-masked]>
Date: Thu, 13 Nov 2008 18:01:32 +0000

> having a rather different discussion.

http://www.ietf.org/internet-drafts/draft-irtf-asrg-bcp-blacklists-04.txt

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
ROCKALL MALIN HEBRIDES: SOUTHWEST 5 TO 7, INCREASING 7 OR GALE 8, PERHAPS
SEVERE GALE 9 LATER. ROUGH OR VERY ROUGH. RAIN, FOG PATCHES. MODERATE OR GOOD,
OCCASIONALLY VERY POOR.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 13 Nov 2008 13:08:41 -0500

I'm violating my normal rate limits here, but since this is the second
time today someone twitted me for this, I need to clarify.

On Thu, Nov 13, 2008 at 12:53:31PM -0500, Chris Lewis wrote:

> Behaviour of DNSBL != information transfer protocol.  

What I meant by "behaviour" above is "how the protocol behaves", and
not "how the administrators behave" or "how things behave given this
or that data".  This is a failure in my formulation, and I regret it.

As I noted (with Olafur) in our posting the other day, the problem _I_
have with DNSBLs is that they're doing fairly serious damage to the
DNS protocol.  That's a fact of life given the deployed software, but
I don't think it's a good thing.

I refuse to state an opinion on how DNSBLs ought to be operated so
that users' expectations of behaviour of the service are met.

A

---

From: John C Klensin <[email-masked]>
Date: Thu, 13 Nov 2008 13:15:55 -0500

--On Thursday, 13 November, 2008 18:01 +0000 Tony Finch
<[email-masked]> wrote:

>> about subjective opinions of "behaving badly", we would, IMO,
>> be having a rather different discussion.
> 

Sorry, Tony, I'm aware of the existence of that draft.

Procedurally, it takes us back to exactly the problem I'm trying
to identify, quite independent of the substance of the DNSBL
debate.  

That document is under consideration in an RG.  As far as I
know, there has been no assertion of RG consensus (whatever that
might mean).  If I recall, one of the authors even indicated
that it needed to be revised further.  It is not a WG product
that was authorized in the WG's charter.  I don't believe that
anyone has asked that it be standardized (or published as a
BCP).  Certainly no IETF Last Call has been issued.

And that is exactly the point I was making -- with a WG, we have
the opportunity, at charter time, to discuss the complex of
documents that are needed and even to make decisions about what
should be considered first.  ADs get to look at the entire set
of proposed WG documents and make decisions (subject to
discussion and appeal if needed) about what documents should be
considered by the IETF together or in a specific order.

Here we are being asked to standardize a set of data formats
without the BCP and framework documents that make that
consideration meaningful and, as others have pointed out,
without documentation of consequences, risks, and relationships
that belongs somewhere in a set of documents.  I don't know if
those appear in adequate form elsewhere in the set, but I do
know that they are not in the document in front of the IETF and
that some of us believe that, without them, the document should
not be approved on the standards track.

And all of that would be true even if more of us were huge fans
of RBLs.

regards,
     john

---

From: Matthias Leisi <[email-masked]>
Date: Thu, 13 Nov 2008 19:25:32 +0100

> I don't think it's a good thing.

Can you please explain what this "fairly serious damage to the DNS
protocol" is?

-- Matthias

---

From: "Al Iverson" <[email-masked]>
Date: Thu, 13 Nov 2008 13:34:27 -0500

> Can you please explain what this "fairly serious damage to the DNS

I would also like to better understand this concern.

Regards,
Al

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 13 Nov 2008 13:39:19 -0500

> Can you please explain what this "fairly serious damage to the DNS

The message I posted from Olafur and me the other day is supposed to
explain this already:

http://www.ietf.org/mail-archive/web/ietf/current/msg53776.html

For the impatient, one fundamental problem is that the current
behaviour uses A records that do not contain host addresses, which is
contrary to the definition of an A record.

A

---

From: John C Klensin <[email-masked]>
Date: Thu, 13 Nov 2008 13:40:18 -0500

--On Thursday, 13 November, 2008 12:53 -0500 Chris Lewis
<[email-masked]> wrote:

>> 2.  DNSBLs are in themselves bad, because there is no way to
>> guarantee that they won't contain false positives; they are
>> nevertheless possibly useful, but the trade-offs are
>> inadequeately described in the current document.
> 
> If all that's missing is a few sentences in the Security
> Considerations section, I'm sure that we can get somewhere
> with that, on the other hand, discussion of those types of
> tradeoffs probably don't belong in this draft, but a BCP.

But there is no BCP.  There is a draft that has been cited a few
times, but no request for the IETF to review and publish it.  It
has never been the practice for the IETF to approve a
standards-track document that is known to be too weak without
some material with the promise that material will appear at some
point in the future and will be adequate.

Chris, I can't promise success, but let me at least suggest how
to have a very different, and potentially more constructive,
discussion.

(1) This document gets withdrawn, or at least suspended, in its
current form. 

(2) You and your colleagues ask for a WG.  If there is as much
consensus and work done already as we have been told, it could
have a very aggressive schedule.   However, the draft charter
should reflect the set of documents you think are needed, how
they connect to each other, and what topics they cover.  It
should also permit a clear discussion about the community's
expectations and conditions for approach of DNSBL documents,
independent of trying to pick apart (or advance) one particular
document.

(3) If you can get that charter approved, you submit documents
that are closely related either together or in some sequence
consistent with the charter and/or their relationships.  

If you cannot get the charter approved, then I think this is
hopeless unless you decide to simply publish a series of
Informational documents with clear statements about what they
represent.

Just my opinion of course, but it appears to me that the present
discussions are going nowhere that is likely to lead to
standardization of the current document in its present form.
The observation that both those who favor standards-track
publication of the document and those who dislike it (or RBLs
generally) for one reason or another are kicking the same dead
horse  (Lisa has already posting a note indicating that she
doesn't see sufficient consensus to support the document for
standardization in its current form, which makes it dead unless
another IESG member comes forward to sponsor it) moves neither
the document nor the discussion forward.

      john

---

From: Ted Hardie <[email-masked]>
Date: Thu, 13 Nov 2008 10:51:28 -0800

>contrary to the definition of an A record.

Andrew,
	Thanks for the pointer. I had missed this technical comment in
the crowd, and I think it is very important indeed.  By re-using RRs with
context-specific semantics, the proposal does serious harm to interoperability.

	Andrew and Olafur suggest one way around this (give a new RR for this use);
there are others, but this one is both available and makes sense for this usage.
They note that it would take some time to get this deployed.  I believe that
the rate of update among DNS-based reputation services is somewhat higher
than Andrew and Olafur seem to, but the change should go forward *whether
this draft is standardized or not*.  It's important for the interoperable understanding
of the DNS namespace for this to occur (or one of the related methods, like using
a class other than IN to occur).

			regards,
					Ted Hardie

---

From: Matthias Leisi <[email-masked]>
Date: Thu, 13 Nov 2008 20:04:11 +0100

> contrary to the definition of an A record.

And this counts as "fairly serious damage to the DNS protocol"? This
seems like a *tiny* bit exaggerated.

The suggestion to use a dedicated RRTYPE is nice, but many others have
failed in this endeavour before.

-- Matthias

---

From: Ted Hardie <[email-masked]>
Date: Thu, 13 Nov 2008 11:19:47 -0800

>failed in this endeavour before.

What do you mean "failed in this endeavour"?  failed to get an RR
assigned, or failed in deployment?

				regards,
					Ted

---

From: Tony Finch <[email-masked]>
Date: Thu, 13 Nov 2008 19:23:05 +0000

On Thu, 13 Nov 2008, Ted Hardie wrote:
>
> Thanks for the pointer. I had missed this technical comment in the
> crowd, and I think it is very important indeed.  By re-using RRs with

Is there any evidence for that?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
VIKING NORTH UTSIRE SOUTH UTSIRE: SOUTHERLY OR SOUTHWESTERLY 5 TO 7,
OCCASIONALLY GALE 8 IN NORTH UTSIRE AT FIRST, AND PERHAPS GALE 8 IN VIKING
LATER. ROUGH OR VERY ROUGH. RAIN. MODERATE OR GOOD, OCCASIONALLY POOR.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Ted Hardie <[email-masked]>
Date: Thu, 13 Nov 2008 12:08:17 -0800

>Is there any evidence for that?

The draft currently says:

   DNSxLs also MAY contain an A record at the apex of the DNSxL zone
   that points to a web server, so that anyone wishing to learn about
   the bad.example.net DNSBL can check http://bad.example.net.

That's an example in which an A record in this zone has the standard DNS meaning
and the expectation is that you can use it construct a URI.  The other A records have
a specific meaning in which the data returned indicates that indicates something about
its reputation in a specific context (what reputation etc. being context specific).  One
of these things is not like the other.  Using the same record type for both  creates
a need to generate some other context that enables you to figure out what was really meant.

The whole approach here is "An A record in this zone has a meaning different from
the meaning in other zones".   That creates a DNS context for the RRTYPE based on
the zone of the query, which is not what the DNS currently uses for disambiguating
the types of requests/responses.  Using a different RR type puts you back into
the standard way of doing things.

			regards,
				Ted Hardie

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 13 Nov 2008 15:21:50 -0500

> seems like a *tiny* bit exaggerated.

The DNS is a distributed, loosely-coherent database of typed data.  If
we start throwing away the types, it seems like pretty serious damage
to me. 

When my DNS client gets back an A record from what appears to be a DNS
server answering DNS queries according to the standard DNS protocol,
it ought to be able to rely on the the A record containing a host
address, because that's what an A record is defined as containing (by
RFC 1035).  But the DNSxL document describes using A records such that
that the RDATA contains something that looks like a host address, _but
that isn't_.  There's no way to tell that such is the case except by
knowing the context of the query and the contents of the response.
What this does is make the answer different _in kind_ depending on its
content.  Note that this isn't like the (otherwise lamentable) example
of TXT records being used as protocol elements -- they at least were
always defined as being nothing more strongly typed than text strings.

If the "protocol" as described in the -dnsbl- draft does not do
violence to the DNS protocol, then I guess I don't know what would.

I thought this argument was plain in the original note Olafur and I
sent, but I gather technical comments of this nature might have been
lost in the fog (well, flames, in this case) of war.  I hope the above
clarifies.

I should observe that I'm not so naive as to suppose the existing use
is going to disappear any time soon.  That's a poor reason, in my
opinion, for turning a bad use into a "standard" of any kind, when we
can instead document the existing (bad) use for everyone's
information, and suggest an alternative that accomplishes the same
goal without causing the same harm.  If that's not the point of an
interoperability-focussed network standards organization, I guess I
also don't know what we're doing here.

A

---

From: Ted Hardie <[email-masked]>
Date: Thu, 13 Nov 2008 12:58:58 -0800

At 12:08 PM -0800 11/13/08, Ted Hardie wrote:
> The other A records have

I see that my brain didn't get this down to my fingers as I intended
(or should as I "indicated").  Please read Andrew's note on this same
topic  but with the subject line "Clarifying harm to DNS" instead. 
He's more cogent, the originator of the comment, and he and Olafur
still have my support that their point needs to be addressed.

Thanks,
		Ted Hardie

---

From: Steve Linford <[email-masked]>
Date: Thu, 13 Nov 2008 21:30:06 +0000

> contrary to the definition of an A record.

Is this not a truly desperate grasping at straws?

So far I have heard here:

- DNSBLs are not much used so they should not be recognized.
   (we alone have 1.4 billion end-users and our DNSBLs are used by
   2/3 of internet networks, including all giant freemail providers)

- DNSBLs are temporary fad, they'll never last.
   (we've been serving DNSBLs for 10 years)

- DNSBLs are bad for email.
   (we alone flag some 80 billion spam emails *per day*, spam which
   would otherwise clog servers and render email completely useless)

- DNSBLs stop very little spam.
   (our DNSBLs catch 80-90% of spam out-front, and 99% if used as we
   recommend in: http://www.spamhaus.org/effective_filtering.html )

- DNSBLs have huge False Positives.
   (at 80 billion spams stopped per day, if we had even a miniscule
   FP level there would be a worldwide outcry and everyone would stop
   using us. Do the maths. Our FP level is many times lower than any
   other spam filter method by a very, very long way)

- DNSBLs break email deliverability.
   (DNSBL technology in fact ensures that the email sender is notified
   if an email is rejected, unlike Bayesian filters/content filters
   which place spam in the user's trash without notifying the senders)

- DNSBLs "sit in the middle of an end-to-end email transaction"
   (see: http://www.spamhaus.org/dnsbl_function.html for enlightenment)

- IETF should not recognize DNSBLs because it may upset IETF sponsors.
   (the IETF sponsors and founders list reads as a "who's who" of DNSBL
   users, we ourselves have contracts with at least 60% of the IETF
   sponsor corporations for the use of our DNSBLs. Upset them my foot.)

- Someone from BT said "DNSBLs should not be standardised"
   (BT has a contract with Spamhaus to use our DNSBLs on its network,
   we're not sure why BT would prefer the DNSBLs it uses to not be
   standardised but we'll ask them at contract renewal time ;)

- DNSBLs are all bad because someone had a bad experience with SORBS.
   (well, we're not SORBS. Nor are Trend Micro, Ironport, or the other
   responsible DNSBL operators)

and

- DNSBLs cause "fairly serious damage to the DNS protocol" because they
   use A records that do not contain host addresses.
   (127.0.0.0 is reserved for IANA Special Use. It is non-net-routable.
   DNSBLs using 127.0.0.2 cause absolutely no 'damage' whatsoever)

Please could the arguments against standardisation use some better  
and correct facts, as most of the arguments being presented against  
standardisation started off poor and are deteriorating into farcical.

   Steve Linford
   Chief Executive
   The Spamhaus Project
   http://www.spamhaus.org

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 13 Nov 2008 14:05:58 -0800

Since I have been critical of the insistence on a new RR in other contexts, I will give the reasons why I am unconvinced in this particular case and indeed would argue that a specific RR would be more effective.
 
First, let us consider the reasons why you might want to re-use an RR rather than define a new one:
 
1) Avoid running out of RRs.
 
2) Incompatibility with existing DNS infrastructure
2a) DNS publishing server
2b) DNS caching/lookup server
2c) DNS client
(Yes, I find the standard nomenclaure confusing and ambiguous)

I do not see that the first objection applies in this case. This is a very specific application, it is providing a description of a part of the Internet address space which is a primary function of the DNS.
 
Where I do see creation of new RRs to be a concern is in cases where there is a combinatorial issue, for example a scheme that would require a new RR to be created for each Internet application protocol. That gets us into the same problem as port exhaustion and is unacceptable.

The second issue is somewhat different to the analysis for DKIM or other enterprise deployments. A DNSBL is almost always deployed by a specialist on dedicated infrastructure. I do not see any reason to object to a scheme that would require such a specialist to upgrade their DNS publishing server.
 
The same is also true at the client end. Email infrastructure that uses a DNSBL should not be using the local DNS resolver to cache data. If the data is worth caching cache it in the email server. If you have enough email servers to make another arrangement worthwhile you have enough to know exactly what you are doing.

Against this there is the fact that the original Vixie DNSBL spec is terrible. Reuse of the A record makes the somewhat bizarre assumption that all the info that you might want to put into a blacklist can be encoded into a 32 bit binary field.
 
At least use a TXT record if you are going to go that route. Take the opportunity to get a little more descriptive info in there. For example, is the basis for the info objective or subjective when was the information last updated?

One problem with DNSBLs is that some folk start a service because they think it might be fun and then get bored with maintenance but the server stays up in perpetuity. Its like one of those abandonded lobster pots that just acts as a permanent death trap for sea creatures.
 
I know that there are less people starting email blacklists today, but just wait till the next set of blacklists are required. We will have the same process of boom - bust and gradual decay. Having some better info on what the age of the complaint is would be a big improvement. At least that way the DNSBLs that are designed in good faith will automatically disable themselves over time.

From: [email-masked] on behalf of Ted Hardie
Sent: Thu 11/13/2008 3:08 PM
To: Tony Finch
Cc: [email-masked]
Subject: Context specific semantics was Re: uncooperative DNSBLs, wasseveral messages

   DNSxLs also MAY contain an A record at the apex of the DNSxL zone
   that points to a web server, so that anyone wishing to learn about
   the bad.example.net DNSBL can check http://bad.example.net <http://bad.example.net/> .

                        regards,
                                Ted Hardie

---

From: Peter Dambier <[email-masked]>
Date: Thu, 13 Nov 2008 23:32:12 +0100

Windows is one of the most prominent users of DNS.

I remember you could send them netbios packets and
windows would put them into the DNS cache.

Be asured they will put dnsbl into the cache and
then the famous IE will look for cnn.com on 127.0.0.1

It makes sense after all because the spammers do host
malware sites too. Looking up a dnsbl will prevent
your browser from accidently showing malware sites :)

Be asured sooner or later some silly bugger will try
and it works - no more malware and no popups either.

Kind regards
Peter

-- 
Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Rimbacher Strasse 16
D-69509 Moerlenbach-Bonsweiher
+49(6209)795-816 (Telekom)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [email-masked]
http://www.peter-dambier.de/
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: David Romerstein <[email-masked]>
Date: Thu, 13 Nov 2008 14:40:07 -0800 (PST)

> CNAME, not PTR. SORBS *appears* to want PTRs (with appropriate TTLs).

Following up to myself (bad form!), I'm mistaken. This IP was probably 
originally listed because it's in a huge swath of hostnames with generic 
rDNS. I submitted a ticket to have it delisted, was rejected by the robot, 
and found (in discussion w/the SORBS admin[1]) that a DNS lookup on that 
IP failed:

[86400] 141.17.85.65.in-addr.arpa domain name pointer newgate.xpasc.com.
Host 142.17.85.65.in-addr.arpa query failed: Connection Timed Out
[86400] 143.17.85.65.in-addr.arpa CNAME pointer 65.85.17.143.xpasc.com.

(Interestingly, out of the whole /24, that's the only lookup that failed)

There's a 48 hour timeout before a new request for this IP can be 
submitted. If this host appears in anyone's MX record, let me know - that 
can push this request to a different queue.

-- D

[1] SORBS' admin, who answered by despite being on a well-deserved 
holiday
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Peter Dambier <[email-masked]>
Date: Thu, 13 Nov 2008 23:44:48 +0100

e.g. the ".local" TLD.

When microsoft introduced the ".local" TLD for "rendezvous"
incompatibility, their windows boxes started to query the
root-servers for nonsense like "refrigerator.local"

When some hearty nameserver operators fighted back, loading
a zone file for ".local" they brought campus networks down.

Zeroconfig was never meant to query port 53 - but they do.

As soon as some windows gurus see an official document
about dnsbl they will put it into the windows dns.

Looking for cnn.com on 127.0.0.1 will be fun.
Some of those boxes do serve http.

Kind regards
Peter

---

From: Keith Moore <[email-masked]>
Date: Thu, 13 Nov 2008 18:15:53 -0500

> DNSBLs are operated badly, DNSBLs are bad.

I have a strong suspicion that poor design of the DNSBL protocol (and/or
its interface to SMTP and NDNs) encourages more badness than is needed.

For instance, what would happen if mail servers provided feedback to
both senders (on a per message basis in the form of NDNs) and recipients
(say, via a web page that listed messages blocked due to DNSBLs)...in
both cases describing which DNSBL blocked the message and what the
blocking criteria were?

What if recipients could disable blocking on a per-DNSBL basis?

Assuming that we're going to have reputation services, I'm looking for
ways to make them more accountable/responsible.

Keith

---

From: "Chris Lewis" <[email-masked]>
Date: Thu, 13 Nov 2008 20:35:59 -0500

> its interface to SMTP and NDNs) encourages more badness than is needed.

Step back from DNSBLs.  What you are describing is more properly a BCP
for the implementation of email filters in general, and is not directly
relevant to the protocols involved in any one kind of filtering.

These are NOT reputation systems issues.

These are filter implementation issues.

The problems you ascribe below are equally (or more) applicable to
almost all other filtering techniques - whether or not you're relying on
external supplied filtering information.

The ones that this isn't applicable (such as greylisting, or banner
delays for example), are often by their very nature incompatible with
your suggestions (eg: you can't quarantine a banner delay FP).

As such, such considerations really belong in a entirely different
document about filtering in general.  Which is a fine charter for a WG,
more useful than one on DNSBLs or reputation systems specifically.

So, I'm going to attempt to cover your "for instance" from a more
general perspective - showing that your "for instance" scenarios are
already broadly implemented throughout the industry, but there are
problems and caveats that you're not aware of.

> both senders (on a per message basis in the form of NDNs)

They already provide feed back to senders.

Most filtering systems supply NDNs with either a reasonably direct
explanation of what happened (eg: "we don't allow swear words", or "see
http://spamhaus.org/lookup=X"), or provide means by which remediation
can be achieved, eg: "If you believe this is in error, please contact
[email-masked] with the following sessionid ....".

[That's what ours says.]

DNSBLs are perhaps the best at supplying suggested text for the NDN (eg:
TXT records in the protocol spec.).  Other systems aren't so consistent.
But remember, it's only a suggestion.  The filter implementer need not
use it.  We don't.  On purpose.

We have chosen, as a corporate, to not reveal _any_ filtering reasons in
NDNs as a security measure, and get the sender to contact us for
remediation (via the message I quoted above), and explanation if
necessary for remediation.

Any BCP that insists on the NDNs being perfectly transparent about "why
this email was blocked" is going to be rejected by a large chunk of the
industry, DNSBLs or otherwise.

You want to know how to get the email blockage fixed.  That's a
different question than "why was this was blocked".  If you can satisfy
the former, the latter is seldom necessary.

> and recipients
> (say, via a web page that listed messages blocked due to DNSBLs)...

Many systems, particularly the large ones (eg: all outsourced spam
filtering systems, all very large ISP environments etc) provide
recipients with one way or another to examine "filtered email", either
by tagging, junk folder, web-based quarantine, or summary email
notifications - we do the latter two.

> in

Many systems provide direct explanations of the reasons for why the
email is in the quarantine or junk folders.  Probably becomes "Most" if
the user knows how to look.

We've explicitly chosen to inhibit displaying the "reason" to the
recipient for a particular block for three reasons - security (see
above), useability (most users would have difficulty figuring out how to

> What if recipients could disable blocking on a per-DNSBL basis?

They often can.  Many server-based systems implement per-user
customization.  However, experience seems to indicate that such
functionality is almost never used, and when it is, it's almost always a
"all filters on" or "all filters off" choice.

Secondly, as a corporate entity (rather than a service provider), it's
our email flow, and our ultimate responsibility and liability about what
happens on it.  In fact, legislation _requires_ us to filter certain
things.  Therefore, you can't opt out of our filters without a formal
security exemption.  A BCP requiring per-user opt-out won't be
acceptable to the industry.

> ways to make them more accountable/responsible.

Your suggestions can't be implemented by a reputation service.  Only the
filter implementor can, and these suggestions apply equally to all
filtering techniques.  Doesn't belong in a DNSBL protocol specification.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: <[email-masked]>
Date: Fri, 14 Nov 2008 08:19:04 -0000

>    (we've been serving DNSBLs for 10 years)

Longevity is no guarantee of future survival.

>    would otherwise clog servers and render email completely useless)

Interesting point. If you did not run those DNSBLs then the flood of
spam would have rendered email completely useless which would have
reduced the sell-rate from one in 12.5 million, to zero. At which
point there is no financial incentive for spam. Or, more likely, spam
would have been maintained at a much lower level to maximize their
profit.

>    other spam filter method by a very, very long way)

Hmmm. No data provided, so no maths is possible. Note that a huge FP
rate
does not imply a huge quantity of false positives, if you allow for an
importance factor. 

>    which place spam in the user's trash without notifying the senders)

This still breaks deliverability. 

>    (see: http://www.spamhaus.org/dnsbl_function.html for 

There is a diagram under Rights of a Sender vs Rights of a Receiver
which shows that the DNSBL modifies the behavior of the Receiving
mail server. This is what I mean by "sitting in the middle of an
end-to-end (sender to recipient) email transaction.

>    standardised but we'll ask them at contract renewal time ;)

This is the IETF. Nobody here speaks for any company or any
other organisation. Many people have stated that THIS DRAFT should
not be accepted as a STANDARDS TRACK RFC because it does not meet
the IETF requirements for an IETF STANDARD. That is very different
from saying that DNSBLs should not be standardised. 

>    responsible DNSBL operators)

DNSBLs are risky because of the many cases put forward here. This
implies that there are security considerations that should be discussed
in the RFC, but which the authors neglected to mention. 

>    DNSBLs using 127.0.0.2 cause absolutely no 'damage' whatsoever)

You must not have read the draft. People are concerned with stuff 
like this from section 2.3:

   To minimize the number of DNS lookups, multiple sublists can also be
   encoded as bit masks or multiple A records.  With bit masks, the A
   record entry for each IP is the logical OR of the bit masks for all
   of the lists on which the IP appears.  For example, the bit masks for
   the two sublists might be 127.0.0.2 and 127.0.0.4, in which case an
   entry for an IP on both lists would be 127.0.0.6:

In any case, your diatribe will not change the fact that this draft
will not be standardised. In order to become a standard, a draft has
to have consensus, and you can't build consensus by misstating the
arguments against standardisation, and then saying that it is all
farcical.

--Michael Dillon

---

From: Steve Linford <[email-masked]>
Date: Fri, 14 Nov 2008 09:54:49 +0000

On 14 Nov 2008, at 09:19, <[email-masked]>  
<[email-masked]> wrote:

>> - DNSBLs are a temporary fad, they'll never last.

A good argument against publishing a standard for any technology at all.

> would have been maintained at a much lower level to maximize their

The "we don't need filters, the spammers will regulate themselves"  
theory also holds for eliminating the police: crooks will regulate  
themselves when too much crookness renders crooking not so profitable.

This theory can be tested and you guys at BT could be the pioneers:  
turn off BT's spam filters and we'll watch. Obviously let your  
customers know first or your phones will light up (something like  
this will do: "Dear BT customer, we're turning your spam filters off  
as an experiment to see if, over time, spammers will spam you a bit  
less when they realize your mailbox has imploded under the weight of  
spam").

> Hmmm. No data provided, so no maths is possible.

I thought perhaps you might be with BT's mail engineering team. BT  
uses our DNSBLs, you therefore have precise data on both how much  
spam you stop with them and FPs for your customers. (If you're not  
with BT's mail engineering team I apologize)

> This still breaks deliverability.

Deliverability breaks when someone accepts a package, says "250 OK,  
got it" to the courier, and then silently trashes it without  
informing the Sender that the Recipient did not in fact get it.

How many times have you sent an email and your recipient says days  
later "I didn't get it" and you say "well you must have since it  
didn't bounce back" and both of you waste time. Almost guaranteed in  
such cases your recipient was using post-SMTP-phase spam filters,  
content filters or "I guess this looks like spam" filters and the  
receiving server *did* accept your mail, *did* give your server a  
"250 OK, got it" which concluded the transaction and then quietly put  
your message in the Junk.

DNSBL technology maintains the fundemental rule of email  
deliverability: If an email can not be delivered *inform the Sender*.

   Steve Linford
   The Spamhaus Project
   http://www.spamhaus.org

---

From: <[email-masked]>
Date: Fri, 14 Nov 2008 10:48:24 -0000

> A good argument against publishing a standard for any 

Not at all. But it seems to me that the IETF does try
to design standard protocols that have a chance at
longevity.

> This theory can be tested and you guys at BT could be the pioneers:  

I have no idea what theory you are talking about testing.
I was making a comment about what might have been. Obviously,
time has passed and there is no longer any opportunity to test
what might have been.

In addition, my comment about the past had nothing whatsoever
to do with any particular company or ISP. It was a comment
about the feedback loop between DNSBLs and spam volumes. The
more effective DNSBLs are, the more volume of spam is sent
by the spammers who rely on people buying the products that
they advertise.

> I thought perhaps you might be with BT's mail engineering 
> team. 

Not even close. 

> customers. (If you're not with BT's mail engineering team I apologize)

If you promise to not make unwarranted assumptions about
IETF participants in future, then I accept your apology.
You might want to read this <http://www.ietf.org/tao.html>

> How many times have you sent an email and your recipient says 
> days later "I didn't get it" and you say "well you must have 
> since it didn't bounce back" and both of you waste time. 

Yes it's true, the Internet email architecture has a number
of holes that can break deliverability. DNSBLs are only a part
of the problem.

> deliverability: If an email can not be delivered *inform the Sender*.

First of all, the draft only says that there SHOULD be
a TXT record with a reason and that it "is often used"
as the text of an SMTP error response. The draft doesn't
actually say anything at all about informing the sender,
only about the sender's mail server. But then, the draft
is defining the DNSBL protocol, not the entire architecture.

At this point I'm beginning to wonder whether the IETF
should even publish this as an informational RFC. After
all, the information is already public and the authors can
publish the substance of this protocol elsewhere if they choose.
If there was a working group to publish a set of RFCs that
cover the whole area of DNSBLs and filtering then this would
make a fine document for that WG to start with. But on its
own it leaves too many loose ends.

--Michael Dillon

---

From: Tony Finch <[email-masked]>
Date: Fri, 14 Nov 2008 12:11:42 +0000

On Thu, 13 Nov 2008, Ted Hardie wrote:
>
> That's an example in which an A record in this zone has the standard DNS
> meaning and the expectation is that you can use it construct a URI.
> The other A records have a specific meaning in which the data returned
> indicates that indicates something about its reputation in a specific
> context (what reputation etc. being context specific).  One of these
> things is not like the other.  Using the same record type for both
> creates a need to generate some other context that enables you to figure
> out what was really meant.

I understand the argument that DNSBLs break the DNS data model. What I
don't see is any evidence that this causes interoperability problems.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
VIKING NORTH UTSIRE SOUTH UTSIRE: WEST OR SOUTHWEST 5 OR 6 INCREASING 6 TO
GALE 8, OCCASIONALLY SEVERE GALE 9 IN VIKING. ROUGH, BECOMING VERY ROUGH OR
HIGH. RAIN THEN SQUALLY SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR AT FIRST.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: John Levine <[email-masked]>
Date: 14 Nov 2008 13:06:18 -0000

>The whole approach here is "An A record in this zone has a meaning
>different from the meaning in other zones".  That creates a DNS
>context for the RRTYPE based on the zone of the query, which is not
>what the DNS currently uses for disambiguating the types of
>requests/responses.

Didn't that plan go out the window in 1996 with RFC 2052?

> Using a different RR type puts you back into the standard way of
> doing things.

Hypothetically speaking, I sort of agree with you.  But considering
that to a rough order of magnitude, all the MTAs on the net use DNSBLs
the way they work now, you'd expect the ground to be littered with
bodies if reusing A records caused actual damage.

The only damage I've seen, and I think the only damage anyone else has
seen, is when a speculator puts a wildcard on an abandoned DNSBL
domain.  That's why I documented the pair of test addresses, to defend
against that.  It's certainly a band-aid, but like real life band-aids
it does the job without making things worse and easily enough that
people are actually likely to do it.  What you're proposing is a skin
graft, which would be more elegant if it happened, but it won't.

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: "Hardie, Ted" <[email-masked]>
Date: Fri, 14 Nov 2008 07:45:39 -0800

________________________________________
From: Tony Finch [[email-masked]] On Behalf Of Tony Finch [[email-masked]]
Sent: Friday, November 14, 2008 4:11 AM
To: Hardie, Ted
Cc: Andrew Sullivan; [email-masked]
Subject: Re: Context specific semantics was Re: uncooperative DNSBLs, was several messages

Tony.

Since you now have two different meanings for what an A record is, you now need two
different code trees that understand what A records are, and those code trees are not
interoperable.  Standard libraries called in this circumstance won't work, and you'll
need some mechanism to disambiguate the context so you know when to call the
special library for a-record-in-dsnbl versus the code in a-record-in-standard-dns.
At the moment, this is by application, but it may not always stay that way.

Since new RRs are substantially easier to get and use than they used to be, Andrew 
and Olafur have suggested that this work transition to using one, so that the current
re-use can be phased out.  I support that, and I would be very concerned about
the IETF standardizing something that breaks the DNS model. We've started down
that path on a couple of occasions, and it hasn't been all that pretty.   Having the
DNS remain a single namespace with as few context dependencies as we can is
pretty important, in my opinion, and the costs to moving back into the standard
way of doing things (over time, as they pointed out) does not appear to be onerous,
especially if tied to some other transition.

regards,

Ted Hardie

---

From: Tony Finch <[email-masked]>
Date: Fri, 14 Nov 2008 16:17:20 +0000

On Fri, 14 Nov 2008, Hardie, Ted wrote:
>
> Since you now have two different meanings for what an A record is, you
> now need two different code trees that understand what A records are,
> and those code trees are not interoperable.

What do you mean by "interoperable" here? What would it mean for DNSBL
lookup code to interoperate with host address lookup code?

> Standard libraries called in this circumstance won't work,

In the code I'm familiar with, most of the DNS lookups go through the
standard resolver library's res_search() interface, including host
lookups, MX lookups, DNSBL lookups, etc. The structure of the code would
not be the slightest bit different if DNSBLs had their own RR type.

> and you'll need some mechanism to disambiguate the context so you know
> when to call the special library for a-record-in-dsnbl versus the code
> in a-record-in-standard-dns. At the moment, this is by application, but
> it may not always stay that way.

I wouldn't say per-application: it's more like per-feature.

Note that I'm not arguing against a new RR type, I'm just trying to
understand the arguments against the de facto standard.

One significant advantage which I have not seen clearly articulated is
that a new RR type could combine the functions that are currently
performed by A records (bit vector) and TXT records (explanatory URL)
which could greatly reduce the number DNS lookups.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
SOUTHEAST ICELAND: CYCLONIC BECOMING WESTERLY, 6 TO GALE 8, PERHAPS SEVERE
GALE 9 LATER. VERY ROUGH OR HIGH. RAIN THEN SHOWERS. MODERATE OR GOOD.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Rich Kulawiec <[email-masked]>
Date: Thu, 13 Nov 2008 11:56:01 -0500

> I can't notify the subscriber, because their ISP also rejects my email.

This is not a DNSBL problem.  This is a problem with the subscriber's ISP,
which is not operating their mail system per de facto best practices --
which include making sure that rejection notices provide an alternate-channel
means of contacting them in order to discuss apparently-erroneous blocking.
There are a sizable number of techniques for doing this; I happen to think
the best ones are quite simple, e.g.:

	reject=550 5.7.1 <[email-masked]>... Mail refused - [201.45.252.2] listed by Spamhaus (http://www.spamhaus.org) - forward this message to [email-masked] if you believe this is a mistake

of course [email-masked] needs to be exempted from the same
blocking and should forward to the postmaster/abuse staff at example.com.

There are many other ways to accomplish the same thing at minimal effort
and cost; the unifying factor they all share is that recognize that all
anti-spam setups have non-zero FP rates, so it's a good idea to be prepared
to deal with those situations when they arise.

---Rsk

---

From: Rich Kulawiec <[email-masked]>
Date: Thu, 13 Nov 2008 20:43:26 -0500

> both cases describing which DNSBL blocked the message and what the

These things are all outside the scope of this document, because they
pertain to how DNSBLs should be used, not how they should be operated.

(They're also not good ideas.  In the former case, backscatter/outscatter
spam will result.  In the latter case, presenting users with a list of
hundreds of messages per day serves no useful purpose.)

---Rsk

---

From: "Al Iverson" <[email-masked]>
Date: Fri, 14 Nov 2008 12:31:21 -0500

> This still breaks deliverability.

How?

> end-to-end (sender to recipient) email transaction.

At the desire of the receiving mail site's administrator.

And is not unique to DNSBLs. Any sort of spam filtering modifies the
behavior of the receiving mail server.

Regards,
Al Iverson

---

From: Ted Hardie <[email-masked]>
Date: Fri, 14 Nov 2008 09:41:45 -0800

>Didn't that plan go out the window in 1996 with RFC 2052?

Sorry, what about SRV made RRTYPE not significant?  Sorry
to be dense, but I don't understand your point here.

>graft, which would be more elegant if it happened, but it won't.

I believe Andrew and Olafur quite sensibly proposed that this change
go forward with a transition to allow for increasing numbers of v6
addresses.  There are other ways to accomplish a transition, obviously,
but I didn't hear them say (and I didn't mean to say) "stop what you're
doing *right now* or the Internet police will round you up".  They suggested
a way of moving back to the actual DNS model while not breaking
existing systems. 

For very good reasons, few of the people putting together systems
are really aware of the full context in which an RFC gets written;
that means many of the readers are looking to one or two RFCs
as a pattern for what they wish to do.  If you write into a standard
"Reusing A records is fine, provided you have a disambiguating
domain name", you can expect other people to use that outside
the original context.  The real damage might well occur when it leaks
out of DNSBLs into the next bright spark for web-based reputation
or something similar.

			regards,
				Ted Hardie

---

From: Ted Hardie <[email-masked]>
Date: Fri, 14 Nov 2008 09:49:46 -0800

>which could greatly reduce the number DNS lookups.

I don't think is really the right list to go into this in detail, but I
agree that there are potential benefits to shifting to a new RR beyond
those related to the coherence of the DNS model.  Depending on
the syntax, it could well give you ways to distinguish among cases
which I believe some DNSBLs conflate now. For example, giving you
ways of distinguishing among the following cases:

1) We have no data, positive or negative, about the record queried.

2) We have data about the record queried and it has a positive reputation

3) We have data about the record queried and it is mixed; we see spam
and we see  non-spam email as well.

4) We have data about the record queried and we believe to be all spam

1 & 2 are easily conflated, as are 3 and 4.  Giving you richer ways
of handling that would enable you to let the customer make more
individualized decisions.  Data on the freshness of the information is also
not easily carried in the A-record style response (without then re-using
another aspect of the DNS, the TTL, in a subtly different way).  Many users
may not want to interpret this data, obviously, as they want the simplest check
possible so that run-time processing is possible.  But it is trivially easy
to re-conflate.

			regards,
				Ted Hardie

---

From: John C Klensin <[email-masked]>
Date: Fri, 14 Nov 2008 13:45:51 -0500

--On Thursday, 13 November, 2008 11:56 -0500 Rich Kulawiec
<[email-masked]> wrote:

>> Huh?  Concrete, real example:  I send a message to an IETF
>> mailing list. A list subscriber's ISP rejects the forwarded
>> message.  IETF's mailman drops the subscriber, because this
>> has been happened multiple times. I can't notify the
>> subscriber, because their ISP also rejects my email.
> 
> This is not a DNSBL problem.  This is a problem with the
> subscriber's ISP, which is not operating their mail system per
> de facto best practices -- which include making sure that
> rejection notices provide an alternate-channel means of
> contacting them in order to discuss apparently-erroneous
> blocking. There are a sizable number of techniques for doing
> this; I happen to think the best ones are quite simple, e.g.:
>...

Sigh.

Rich, you can blame "someone else" all you like, but the reality
here is that 

(1) If the system supporting the DNSBL is following the email
protocols and decides to reject the message or bounce it, rather
than, e.g., assigning a score and moving it into the
user-related mail store, it replies back to the IETF list
manager, not the original sender.  That means that the original
sender never finds out that the subscriber didn't get the
message.  Indeed, there are other standards and norms that
suggest that telling the sender is a privacy problem.

(2) If that IETF server gets back a reject (i.e., a reply code,
not an NDN) and follow the letter of the SMTP protocol, all it
knows is that it got a permanent message rejection  (5yz code)
for a particular address.  If it has logic to count the number
of rejections for a particular address and does so, you've got
exactly the situation Randy posits.  The sender doesn't find
out; the subscriber is left to notice a reduction in mail
received and to then try to figure out what happened in what may
be a very hostile environment.

(3) If that IETF server gets back an NDN -- either because the
DNSBL system is organized to send NDNs rather than rejecting
messages or because there are relays (including SMTP-handling
firewalls) involved -- things are basically hopeless because the
number of mailing list servers that are able to accept NDN
messages, correlate them with particular addresses on particular
mailing lists, and take action on that basis is, well, small.
Of course, one could "solve" that problem by sending the NDN
back to the original message submitter, but that both violates
the email specs and may violate privacy constraints.  Of course,
that list manager could be set up to route the NDNs to a human
list manager but, especially if there are a lot of them,
expecting the list manager to start making phone calls or engage
in an extended email dialogue to track things down is
unrealistic (I just verified empirically that reporting this
type of problem to one of the large email providers who has been
vocal in this discussion requires a phone call (no online
reporting mechanism could be found), a long time on hold, and
then talking with someone who was distinctly uninterested in the
problem and didn't know (or wasn't interested in revealing) who
the customer should talk with.    You may believe that indicates
a poorly-run system; I assume you that the operator would claim
theirs is one of the best (indeed, that claim has been made on
this list).

If the answer is that the email protocols are now "wrong" given
the demonstrated need for blacklists, then propose changes and
see if you can get consensus.  If you believe that the problem
is the absence of established best practices, then charter a WG
and produce such a document after having realistically done the
case analyses about who is getting notified and who is supposed
to be responsible to whom.  But please don't waste our time
blaming the subscriber or the subscriber's ISP based on de facto
best practices that haven't been through any consensus process
that ISP can reasonably be expected to know about.

And please don't conflate "score and deliver" systems (which,
admittedly, have their own problems) with "reject, bounce, or
discard mail" systems.

     john

---

From: "Al Iverson" <[email-masked]>
Date: Fri, 14 Nov 2008 13:51:14 -0500

On Fri, Nov 14, 2008 at 1:45 PM, John C Klensin <[email-masked]> wrote:
> manager, not the original sender.

This strikes me as unrelated to DNSBLs. Am I misunderstanding? How is
this DNSBL-specific?

Regards,
Al Iverson

---

From: John L <[email-masked]>
Date: Fri, 14 Nov 2008 18:56:20 +0000 (GMT)

> to be dense, but I don't understand your point here.

A SRV record with _tcp in its name means something different from a SRV 
query with _udp in its name.  I suppose you could argue that's different 
because _names are special, but the semantics are definitely in the name, 
not just in the RR.

> addresses.

You can do that if you want, but since there is no realistic scenario in 
which MTAs will handle v6 DNSBLs differently from v4 DNSBLs, I don't see 
the point in allocating an RR that will not in practice be used.

> The real damage might well occur when it leaks out of DNSBLs into the 
> next bright spark for web-based reputation or something similar.

I fear it is about 15 years too late to fight that battle.  There are 
already domain based DNSxLs, and they encode their stuff into A records.

R's,
John

---

From: <[email-masked]>
Date: Fri, 14 Nov 2008 18:59:01 -0000

> > This still breaks deliverability.

A user writes an email and sends it to another user. The other user does
not receive the email. This means that deliverability is broken. The
DNSBL is an agent in preventing that delivery. To my mind, this deserves
some explicit discussion in the Security Considerations section. On one
hand, a misused DNSBL can wreak havoc, and on the other hand a
compromised DNSBL could block more email than an administrator wishes.
The draft presented by the ASRG was very weak in its discussion of
security considerations given the fact that a DNSBL is explicitly
designed to break email deliverability.

> > which shows that the DNSBL modifies the behavior of the 
> Receiving mail 
> > server. This is what I mean by "sitting in the middle of an 
> end-to-end 

That is irrelevant. The fact is that it does sit in the middle and the
implications of this should be clearly documented.

> And is not unique to DNSBLs. Any sort of spam filtering 
> modifies the behavior of the receiving mail server.

But that would be a topic for another RFC which should also have 
a substantial Security Considerations section.

There are a number of reasons to document something in a standards
document. One is to help people build compatible implementations of
a protocol. Another is to help operators of the protocol interoperate.
But it is also to provide a clear description of the protocol so
that others can improve on it in the future, or replace it entirely
with a superior architecture.

--Michael Dillon

---

From: "Al Iverson" <[email-masked]>
Date: Fri, 14 Nov 2008 14:03:32 -0500

On Fri, Nov 14, 2008 at 1:59 PM,  <[email-masked]> wrote:

Thanks, appreciate the insight.

> DNSBL is an agent in preventing that delivery.

Is this unique to DNSBLs? If not, then why does it merit deeper
consideration in the context of DNSBLs?

Regards,
Al Iverson

---

From: <[email-masked]>
Date: Fri, 14 Nov 2008 19:11:55 -0000

> > A user writes an email and sends it to another user. The other user 
> > does not receive the email. This means that deliverability 
> is broken. 
> > The DNSBL is an agent in preventing that delivery.
> 
> Is this unique to DNSBLs? If not, then why does it merit 
> deeper consideration in the context of DNSBLs?

Because the draft
<http://www.ietf.org/internet-drafts/draft-irtf-asrg-dnsbl-07.txt>
that started this discussion has set the context of DNSBLs.
You are right that it also merits deeper consideration in other
contexts.

--Michael Dillon

---

From: John C Klensin <[email-masked]>
Date: Fri, 14 Nov 2008 14:50:07 -0500

--On Friday, 14 November, 2008 13:51 -0500 Al Iverson
<[email-masked]> wrote:

>...
> This strikes me as unrelated to DNSBLs. Am I misunderstanding?
> How is this DNSBL-specific?

Al, and others,

While many of us are less opposed to DNSBLs in principle than
you or your colleagues may be assuming, we are opposed to
creating IETF Standards for anything that interacts with the
email environment without a relatively comprehensive
understanding (and good documentation) of how the new bits
interact with the rest of the system.  One of the implications
of that is unwillingness to see DNSBL formats standardized
without having any protocol or best-practice documents that are
being assumed in front of us at the same time.   If there are
failure cases, we expect to see descriptions of them and
analyses of either their consequences or how they might be
mitigated.

When DNS experts claim that a particular approach is unhealthy
for the DNS and give careful explanations for that, advocates of
DNSBL standardization need to evaluate those arguments and
propose remedies _in the relevant documents_, not just in
flaming on the mailing list.

When someone asserts that DNSBLs don't cause operational
problems with the mail system if they are operated according to
best practices, then it is reasonable for the IETF to require
that documentation of the relevant best practices be put forward
for standardization as part of the same logical package.
Moreover, when a DNSBL advocate claims that his ISP organization
is using best practices and not having problems or complaints,
counterexamples that indicate that they are filtering complaints
and/or that the supposed best practices are not sufficient or
effective are very much in order.

The purpose of IETF-wide review is precisely to bring out these
"that has implications outside the particular focus of the
developers" issues and force them to be discussed and resolved
before a standards-track document can be approved.  Although
this one has been, IMO, a little more hostile than necessary (on
both sides), anyone who isn't interested in that type of review
should not be looking for IETF Standardization.

Put differently, some of us who might not be resistant to a
collection of documents that made up a DNSBL standard are
extremely resistant to getting documents piecemeal and maybe out
of the order of logical dependencies and get even more resistant
when people try to justify one of the pieces on the basis that
all claimed operational problems are someone else's fault and
therefore not relevant to the document under discussion.

Your opinion may differ, but my personal impression of the rough
consensus is that neither this document, nor any of the probably
followups, should be approved for the standards-track or BCP
until some fairly large set of issues are addressed in a
meaningful way.  There have been a lot of suggestions about how
to do that, most of which I consider constructive, and there may
not be consensus about which ones of  them are optimal.  My own
favorite starts with a draft WG charter whose function includes
mapping out all of the documents needed to make a complete
picture; others may have better (or other) ideas.  The next step
is probably up to the advocates of this document and, IMO,
further attempts to narrow the discussion or dismiss the various
concerns without either a charter or one or more new or revised
documents are not likely to result in the sort of progress you
would like.

   best wishes,
    john

---

From: "Chris Lewis" <[email-masked]>
Date: Fri, 14 Nov 2008 14:55:32 -0500

> suggest that telling the sender is a privacy problem.

Whoa.  You have this almost precisely backwards.

In virtually all cases if the recipient's mail server is using a DNSBL,
and it rejects an IETF-forwarded list item, it's because ietf.org's
_own_ mail server is listed, and the ietf.org list admin is the person
most properly informed of that fact.  Which they will be by existing
standard.

In fact, if the DNSBL was widely used and you expected the IETF list to
violate email standards and reply to the From:, the IETF list would be
mailbombing everyone who submitted an article to it with almost as many
copies of their email as there are IETF subscribers, few if any would be
able to do anything about it, and the admins (who are most likely to be
able to address the DNSBL listing) wouldn't know until someone
complained directly to them.

>From a different angle, in the use-case at hand (IETF items bouncing for
whatever reason), if my email to the list gets bounced by, say, Joe's
(any Joe ;-) mail server, who suffers?  Not me.  Who can fix it?  Not
me.  What's the point of telling me?  There isn't one.  Not to mention
privacy etc.

Bouncing to From:/Reply-to is precisely the WRONG thing to do.  You
won't get argument about that from anyone that I can think of.

[Partially because I remember when a MTA's propensity to bounce to the
From: blew up the first incarnation of the Usenet Moderator's Mailing
list.  15,000 bounces in the first couple hours via dialup.  Ouch.  It
was over a week before the list came back up.  I've caught Exchange 2007
doing it under some circumstances (at one of our own customer lists).
Had 'em disconnected at their ISP until they fixed their server.]

Experience seems to indicate that list owners when presented with
persistent/intractable/difficult-to-handle bounces (other than DNSBL
listings of their own server) simply consider it to be a problem with
the recipient's mail server, unsub, and move on.  Many list packages are
instrumented for just that.

The email standards are quite correct in this space.

The reality is that this "problem" is a MUCH bigger issue with non-DNSBL
filters that do content analysis.

So again: this is NOT a DNSBL/reputation issue, but a filter
implementation issue.

> for a particular address.

Trying to impart better meaning to SMTP protocol returns in terms of
filtering is a filter implementation and SMTP standard issue, not DNSBL.

Secondly, as I'm sure Al Iverson and others can echo, there's
significant amounts of intelligence that can and is be applied to the
errors as they exist today, ESPs do it all the time.

MAAWG has been trying to work this area and produce some sort of SMTP
extension standardish thing (so ESPs can figure out how "permanent" a
"permanent" SMTP error is supposed to be and what they should do about
it), but has self-barred itself from some of the more obvious and
convenient ways of doing this (eg: extensions to the 5.x.x extended SMTP
return codes) by a perceived inability to get such suggestions past the
IETF.  They're probably not wrong for the same reasons that the very
notion of DNSBLs is getting the reception here that it is.

> If it has logic to count the number

Rejects (by DNSBL or any other filter) in no way prevent the recipient
also finding out (by quarantine, junk folder, email notification or
otherwise) that that email was rejected.  Again, this is a filter
implementation BCP issue, not an issue specific to a technique (DNSBL or
content filter or ...).

> mailing lists, and take action on that basis is, well, small.

I don't agree.  In fact, most ESPs, Yahoo, and many common list
implementations (eg: mailman and I believe LISTSERV) have and use this
capability now.  With ESPs, for list pruning.  At times, I've become
quite familiar with Yahoo's "your subscription bounced too often, I've
unsubscribed you, here's how to resubscribe, and <here> is your missed
messages".  Annoying, but no great harm.  Hasn't caused me to change how
the filters that caused those bounces work.

> the email specs and may violate privacy constraints.

It would be precisely the wrong thing to do as outlined above.

> admittedly, have their own problems) with "reject, bounce, or

Please don't conflate "reject, bounce or discard" uniquely with DNSBLs
either.   The former is a general filtering issue.  The latter is merely
one filtering decision technique of many.  DNSBLs (true with most other
techniques) in no way preclude the use of score/junk
folder/quarantine/recipient notify at the same time or in place of
reject/bounce.  Most large implementations do a combination of both on
the same email.  We certainly do.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Keith Moore <[email-masked]>
Date: Fri, 14 Nov 2008 15:01:30 -0500

> consideration in the context of DNSBLs?

what you are arguing is that rather than trying to address the harm done
by DNSBLs, IETF should ignore that harm by ruling it out of scope for
the current discussion.

---

From: "Al Iverson" <[email-masked]>
Date: Fri, 14 Nov 2008 15:10:49 -0500

On Fri, Nov 14, 2008 at 2:50 PM, John C Klensin <[email-masked]> wrote:
> While many of us are less opposed to DNSBLs in principle

You misunderstand. Let's take a step back.

> manager, not the original sender.

Let's reword that a bit.

> (1) If the system supporting spam filtering is following the email

Again, how is this DNSBL-specific?

I'm not trying to fight about whether or not DNSBLs are awesome. I'm
asking clarification for your point, which I'm not understanding. I'm
seeing, for example, a statement that says "DNSBLs do X" when it seems
to actually say "non-delivery of mail actually works like *this*", and
I am unable to see the connection to DNSBLs.

Apologies for not being clearer.

Regards,
Al Iverson

---

From: <[email-masked]>
Date: Fri, 14 Nov 2008 20:12:11 -0000

> Although this one has been, IMO, a little more hostile than 
> necessary (on both sides), anyone who isn't interested in 
> that type of review should not be looking for IETF Standardization.

And for those who have not read the Tao of IETF, the
relevant section is 8.2. Letting Go Gracefully

   The biggest reason some people do not want their
   documents put on the IETF standards track is that
   they must give up change control of the protocol. 
   ...

<http://www.ietf.org/tao.html#anchor37>

--Michael Dillon

---

From: "Al Iverson" <[email-masked]>
Date: Fri, 14 Nov 2008 16:08:50 -0500

> by DNSBLs, IETF should ignore that harm by ruling it out of scope for

I suggested no such thing. I asked for the opposite -- help somebody
who doesn't get it understand exactly what the connection is.

Regards,
Al Iverson

---

From: Ted Hardie <[email-masked]>
Date: Fri, 14 Nov 2008 13:38:54 -0800

>because _names are special, but the semantics are definitely in the name,

I don't see this as a particularly compelling parallel, partly because SRV
was upfront from the beginning that SRV's usage of names was unique:

"The SRV RR is unique in that the name one searches for is not this name;
the example near the end shows this clearly."

This proposal reuses an A record, for which semantics are well established
and which had no such indication.  Further, once you have an SRV record,
the name you used to construct the query doesn't really impact the interpretation
in the same way this proposal seems to.

>already domain based DNSxLs, and they encode their stuff into A records.

If we are documenting practice and nothing more, then the publication
stream can move to informational and text can be added on why
a new RR, which would normally be expected here, is not being used
(essentially, inertia in the face of 15 years deployment).  That may
be a valuable use of an RFC; documenting the way things really work
often is.  But it shouldn't go onto the standards track, as there is a known
technical deficiency.

			regards,
				Ted Hardie

---

From: Douglas Otis <[email-masked]>
Date: Fri, 14 Nov 2008 13:53:31 -0800

On Nov 14, 2008, at 1:38 PM, Ted Hardie wrote:

> If we are documenting practice and nothing more, then the  
> publication stream can move to informational and text can be added  
> on why a new RR, which would normally be expected here, is not being  
> used (essentially, inertia in the face of 15 years deployment).   
> That may be a valuable use of an RFC; documenting the way things  
> really work often is.  But it shouldn't go onto the standards track,  
> as there is a known technical deficiency.

Agreed.

-Doug

---

From: Theodore Tso <[email-masked]>
Date: Fri, 14 Nov 2008 19:04:22 -0500

> who doesn't get it understand exactly what the connection is.

I think the issue of the badly-run DNSBL's can be handled handled by
amplifying the first paragraph of the Security Considerations section.
Currently, it merely talks about the most blantent problems caused by
a DNSBL causing all mail to be rejected, or no mail to be rejected.
It doesn't talk about DNSBL's using different criteria than what they
have advertised for their list, or that a potential DNSBL could use
the trust given to mail receivers to explicitly block an IP block in
retaliation for criticism or to pursue some other vendetta.
Mentioning that these things can and have happened I think is simply
acknowledging the obvious, and that a poorly chosen DNSBL can cause
great harm.

I would also encourage the "how to run a DNSBL responsibly" to be
published at the same time, so that draft-irtf-asrg-dnsbl could
reference the "this is how you do it right" (while acknowledging the
only out of band mechanisms can be used to ensure that a DNSBL
operator is truly following the criteria they claim to be using).

This of course ignores the question of whether a document which is
intended for the Standards Track should be abusing DNS 'A' records or
not.  It may be that a much better approach is to put this on
Informational describing the current state of affirs, warts and all,
and then to create a better document which is Standards Track later
on.

						- Ted

---

From: Theodore Tso <[email-masked]>
Date: Fri, 14 Nov 2008 19:19:33 -0500

On Fri, Nov 14, 2008 at 01:38:54PM -0800, Ted Hardie wrote:
> (essentially, inertia in the face of 15 years deployment).  

If inertia over many years' deployment means that it's essentially
impossible to change things, then maybe it's hopeless to move to
IPv6...  (Oh, wait.... maybe that's why.... Doh!  :-)

Seriously, it's not obvious to me that it's *impossible* to change.
It wouldn't be that hard for DNSBL to carry the information via the
old and new RR records, with the new RR's carry additional information
--- and given that MTA's have to be configured to use a particular
DNSBL's, this is just one additional bit to indicate whether they
should use the old or new RR record --- and for bonus points, there
could be some way of querying the DNSBL, perhaps via a top-level TXT
or SOA record, to indicate whether a particular DNSBL supported the
new RR's or not.

							- Ted

---

From: "Chris Lewis" <[email-masked]>
Date: Fri, 14 Nov 2008 19:25:19 -0500

> operator is truly following the criteria they claim to be using).

In retrospect, putting them up simultaneously might have been a good
idea.  Neither John nor I thought of that.

The latest rev of the BCP is ready for upload, but the IETF web site
won't let me until Monday.  Come Monday, I'll be uploading and posting
pointers in relevant places.

The previous iteration of the BCP was by concensus ready for last call
at the ASRG session in IETF Dublin.  The changes since then are typo
corrections and a minor addition as suggested by the ASRG meeting.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: John Levine <[email-masked]>
Date: 15 Nov 2008 01:05:02 -0000

>both senders (on a per message basis in the form of NDNs)

Well, since 95% of all mail is spam, and all the spam has fake return
addresses, you'd increase the amount of bogus NDNs by more than an
order of magnitude.  No thanks.

Incidentally, on a bad day I already get 400,000 NDNs from mail that I
didn't send, just from the minority of MTAs that send NDNs in response
to spam now.  This is not a hypothetical problem.

R's,
John

---

From: "Chris Lewis" <[email-masked]>
Date: Fri, 14 Nov 2008 20:12:07 -0500

> to spam now.  This is not a hypothetical problem.

Point of order: is NDN "produce bounce" or does it include "reject"?

In my response I took NDN to mean "reject".  Not bounce.

Filters should never bounce (and that would go in a filtering BCP).
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: John L <[email-masked]>
Date: Sat, 15 Nov 2008 01:45:13 +0000 (GMT)

> Seriously, it's not obvious to me that it's *impossible* to change.

Of course it's not impossible.  But the question is whether the benefit 
from the change is large enough that the people who'd have to write the 
software will do so.

IPv4 DNSBLs have been working just dandy with A records for a decade, and 
the benefits of a new RR are largely (perhaps entirely) hypothetical. 
It's hard for me to see anything the IETF could possibly say that would 
persuade the people who actually have to write and maintain the DNSBL 
servers and MTAs and filter packages that they have to do a whole lot of 
extra work when they could just add IPv6 names to the existing IPv4 names 
and be done with it.

R's,
John

> or SOA record, to indicate whether a particular DNSBL supported the

Um, wasn't the point of this suggestion to stop overloading existing RRs 
with new semantics just because they happen to be under certain names?

Without agreeing that a new RR is a good idea, it is nonetheless obvious 
how one would test whether a DNSBL served a new RR type, at least to 
anyone who'd actually read the DNSBL draft.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Peter Dambier <[email-masked]>
Date: Sat, 15 Nov 2008 09:41:52 +0100

Maybe I am a bit late with this idea.

I remeber dns roots switching off and DNSBLs switching off.

Users wont notice until broken - or not even then.

The sysop has been fired.

There should be a means for the DNSBL to tell its client

1) I am not a DNS-server

2) I am going to switch off soon

3) There should be a serialnumber or timestamp on the DNSBL
   to show when it has last been maintained.

When the client sees the wrong type of server it should
warn both the sysop and the user. Today it has no means
to decide so.

Kind regards
Peter

---

From: Steve Linford <[email-masked]>
Date: Sat, 15 Nov 2008 09:00:07 +0000

The standard is to query the DNSBL's Loopback address, 127.0.0.2. If  
the Loopback address does not respond the DNSBL is either shutting  
down or it's defunct. You query the Loopback address like this (using  
our SBL as an example) and should get this answer:

;; QUERY:
;2.0.0.127.sbl.spamhaus.org.

;; ANSWER:
2.0.0.127.sbl.spamhaus.org. 900  IN A   127.0.0.2
2.0.0.127.sbl.spamhaus.org. 1800 IN TXT	
      "http://www.spamhaus.org/SBL/sbl.lasso?query=SBL233"

(if you get no answer to a 2.0.0.127.dnsbl query, the no answer means  
"it's dead Jim" or possibly "it's firewalling you Jim")

Chris Lewis's excellent DNSBL BCP document also covers how to shut a  
DNSBL down properly.

Regards,

   Steve Linford
   The Spamhaus Project
   http://www.spamhaus.org

---

From: Pekka Savola <[email-masked]>
Date: Sat, 15 Nov 2008 15:03:31 +0200 (EET)

> the filters that caused those bounces work.

FWIW, on one mailman mailing-list, I've received the following a 
couple of times; I've not received it on others, which may mean that 
those lists don't enable it, or that the mails on those lists have not 
triggered rejections.  I suspect the former.

"Your membership in the mailing list FOO has been disabled due
to excessive bounces The last bounce received from you was dated
24-Jul-2008.  You will not get any more messages from this list until
you re-enable your membership.  You will receive 3 more reminders like
this before your membership in the list is deleted.
... [what follows is the URL to re-enable membership immediately] "

I have found this message incredibly helpful, and I'd like to see a 
wider application of similar behaviour.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Keith Moore <[email-masked]>
Date: Sun, 16 Nov 2008 12:32:16 -0500

> order of magnitude.  No thanks.

I should clarify.  The way to notify the sender is for the check to be
done at SMTP time, and for the rejecting SMTP server to issue a 5xx SMTP
response to RCPT for that recipient.  This should result in an NDN to be
sent to the sender for legitimate mail.  It will result in an NDN for
spam only when the spam is submitted through somebody's MTA before being
sent to the MX for the recipient.

> to spam now.  This is not a hypothetical problem.

Agreed, it's a very real - and huge - problem.

Keith

---

From: Rich Kulawiec <[email-masked]>
Date: Fri, 14 Nov 2008 15:20:27 -0500

> manager, not the original sender.  [...]

But this, and the rest of your points, have nothing at all to do with
the operation of DNSBLs -- and everything to do with the configuration
of some mail systems which *use* DNSBLs.  The exact same set of issues
might easily arise due to local checks, and often does.

For example, on the mail systems that I operate, 2/3 to 3/4 of all
incoming SMTP traffic is rejected before any DNSBL lookups are done.
Those rejects are functionally identical to those generated as the result
of DNSBL checks; the only difference is the human-readable text.

---Rsk

---

From: "YAO" <[email-masked]>
Date: Tue, 18 Nov 2008 14:24:41 +0800

according to IETF Meeting Venue Selection Criteria
http://tools.ietf.org/html/draft-palet-ietf-meeting-venue-selection-criteria-04#section-2.3

which said "

2.3.  Freedom of Participation

   Meetings should not be held in countries where some attendees could
   be disallowed entry or where freedom of speech is not guaranteed for
   all participants.
"

My question is :"

Is USA qualified for 2.3 of draft-palet-ietf-meeting-venue-selection-criteria as IETF Meeting Venue ?"

It seems that many IETFer are disallowed to enter USA for ietf meeting when ietf is held in USA this time or other times
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Song Haibin <[email-masked]>
Date: Tue, 18 Nov 2008 15:04:36 +0800

My visa application is still under the check in the Shanghai USA embassy
since I submitted it in September 17th. What can I say?

Best Regards,
Song Haibin
Email: [email-masked]
Skype: alexsonghw

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On
>Behalf Of YAO
>Sent: Tuesday, November 18, 2008 2:25 PM
>To: [email-masked]
>Cc: [email-masked]
>Subject: [73attendees] Is USA qualified for 2.3
>ofdraft-palet-ietf-meeting-venue-selection-criteria?
>
>
>
>Is USA qualified for 2.3 of
draft-palet-ietf-meeting-venue-selection-criteria
>as IETF Meeting Venue ?"
>
>It seems that many IETFer are disallowed to enter USA for ietf meeting when
ietf
>is held in USA this time or other times
>73attendees mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/73attendees

---

From: "Tom.Petch" <[email-masked]>
Date: Tue, 18 Nov 2008 16:17:41 +0100

IETF lists are sometimes criticised for their dominance by purveyors of boxes,
by the lack of involvement of those who deploy and depend on those boxes.

A striking feature of this Last Call is the (most welcome) contributions by
these other communities and the fact that, in this instance, an IETF proposed
standard would be most welcome, most helpful, to them.

Furthermore, the points made in favour of this I-D seem to me to be
fundamentally engineering, whereas those against seem more arcane, more
objections on the grounds that the underlying 'purity' of the Internet might be
compromised.

I tracked the lengthy gestation of this I-D on the asrg list and there too, it
struck me that we were engaged in engineering, in producing something that would
work and be of immediate benefit (not something I always see on the lists of
IETF WG)

So, I think that this is a positive and sound response to a major Internet
problem and would like to see it approved for the Standards Track.

Tom Petch

(responding to no message in particular)

---

From: "Phillip Hallam-Baker" <[email-masked]>
Date: Tue, 18 Nov 2008 11:46:40 -0600

No good can come of this thread.

How about we wait a few months and see what happens after the fourth branch
of government becomes part of the executive branch again on Jan 20th?

On Tue, Nov 18, 2008 at 12:24 AM, YAO <[email-masked]> wrote:

> draft-palet-ietf-meeting-venue-selection-criteria as IETF Meeting Venue ?"
>
> ietf is held in USA this time or other times

-- 
Author: The dotCrime Manifesto: How to Stop Internet Crime
http://dotcrimemanifesto.com
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: james woodyatt <[email-masked]>
Date: Tue, 18 Nov 2008 13:38:57 -0600

On Nov 18, 2008, at 00:24, YAO wrote:
>
> It seems that many IETFer are disallowed to enter USA for ietf  
> meeting when ietf is held in USA this time or other times

Has anyone been denied entry to the USA for IETF 73, without official  
explanation, despite their including an IETF invitation with their  
timely visa application to U.S. authorities?  If so, then that might  
be something worth investigating.

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering