Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)

2005-01-13 Thread Andre Oppermann
Steven Champeon wrote:
on Thu, Jan 13, 2005 at 10:25:18AM +0530, Suresh Ramasubramanian wrote:
On Wed, 12 Jan 2005 23:19:47 -0500, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
On Wed, 12 Jan 2005 19:19:24 PST, Dave Crocker said:
In general, that's what dkeys/iim and csv (and maybe spf) are attempting to provide.
Yes, but he asked for a rDNS solution specifically...
I think Steve was referring to some things that can be implemented
right away, like if you operate a mailserver, please make sure that
it isn't on a host that has reverse dns like ppp-XXX.adsl.example.com,
try to give it unique and non generic rDNS, preferably with a hostname
that starts off with smtp-out, mail, mta etc)
Yep. And it helps if the rDNS is right-anchored, (uses subdomains
to distinguish between various assignment types and technologies) a la
 1-2-3-4.dialup.dyn.example.net
   
 4-3-2-1.dsl.static.example.net
^^^
as opposed to 

 dyn-dialup-1-2-3-4.example.net
 static-dsl-4-3-2-1.example.net
as the former is easier to block using even the simplest of antispam
heuristics. I'd love to see a convention, or even a standard, arise for
rDNS naming of legit mail servers. But I'll happily settle for decent
and consistent rDNS naming of everything else ;)
What is wrong with MTAMARK?
MTAMARK tags the reverse entries of IP addresses where SMTP servers are.
Fixes this problem very fast, efficient and with little effort (script
magic to regenerate the reverse DNS entries).
 
ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-stumpf-dns-mtamark-03.txt
--
Andre


RE: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)

2005-01-13 Thread Joseph Johnson

 Basically a call to operators to adopt a consistent forward and
 reverse DNS naming pattern for their mailservers, static IP netblocks,
 dynamic IP netblocks etc.

 ...and to ISPs to facilitate the process by supporting their users who
 want to run mail servers, and helping the rest of us use such techniques
 to quarantine the spew from zombies and less conscientious mail admins.

 I'm always willing to be educated on why it is impossible for any given
 ISP to maintain an in-addr.arpa zone with PTRs for their customers who
 wish to be treated like real admins, as opposed to casual consumer-grade
 users with dynamically assigned addresses.


The problem is it is easier to set it up with a single standard
4-3-2-1.dialup.xyzisp.com then to change the IN-ADDR to mail.customer2.com.
I only have an rDNS entry on the box at home because I used to work for the
ISP.  It's still there only because they probably haven't noticed, and will
not until I draw attention to it or I give up the space if I cancel service.

Still, it took me 3 minutes to put rDNS on most of 7 of 16 in my /28.  It
existed in their provisioning system to do it, but no one knew how.  We
couldn't even market it as a service, because it didn't exist in the
system.  I can't imagine, though, SBC being able to cope with tens of
thousands of small business DSL accounts suddenly needing rDNS on their
static IP's.

Another question, though, is how they handle IN-ADDR and swip for dedicated
circuits.  If they can do it for a T1 customer, can they do it for a DSL
customer?  Maybe an online form the customer can maintain?  Lord knows that
would be better then trying to call their DSL tech support . . . 


Joe Johnson



Re: [eweek article] Window of anonymity when domain exists, whois not updated yet

2005-01-13 Thread Dave Crocker

On Wed, 12 Jan 2005 17:41:33 -0500, [EMAIL PROTECTED] wrote:
  The X.400 concepts of ADMD= and PRMD= really caught on, didn't they? ;)

  Peering in a world of 64K ASNs, mostly basically static, is a lot different
  than peering in a world of 40 million plus .COMs, many in motion.  Most of
  the time, we're lucky if the MX record points to the right place

Funny this should come up now...

I've been working on a document to describe current Internet Mail architecture 
and it has taken an unexpected turn.  In fact I am trying to add a section that 
deals with different Operators, as distinct from different functional modules.  
The reason is primarily because the inter-Operator boundaries define where 
trust relationships need to be decided and enforced. (The recent papers and 
discussions about tussle boundaries captures this issue really well.)

As with so many problems with x.400, it is not that it was wrong to pay 
attention to one or another issue.  The problem was that x.400 mixed everything 
together into a single, homogeneous and gargantuan pot, therefore requiring 
adopters to deal with an ungainly mass of specification and code, all at once.  
You really could not do adoption in incremental steps.  Oh, and this 
all-or-nothing barrier hit the standards guys, too, since some required 
components did not show up for a long time.

The x.400 admd/prmd was, in fact, an addressing construct, rather than merely 
being an operational and routing construct.  Hence, an x.400 address was more 
like a source route.  Arpanet/Internet experience has shown pretty serious 
scaling problems with visible source routing, uucp experience notwithstanding.

The issue we are facing in the current discussion is operations, not 
addressing.  So, for example, the fact of having a variety of operators does 
not show up in the address, any more than it does in an IP address.  Rather, it 
shows up in routing and trust issues, just as it does with IP.

Although lots of operational variety is possible and does occur, perhaps the 
most common operational scenarios are covered by:

origin = [provider =]  [provider =]  destination

And the equivalent to AS-AS trust assessment is not all of the domains in the 
world, but rather domains that involve MTA-MTA exchanges across operator 
boundaries.

I believe the scale of this requirement is exactly the same as the AS-AS 
requirement.

In fact, this is exactly the problem that CSV attends to.

d/
--
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker  a t ...
WE'VE MOVED to:  www.bbiw.net



Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)

2005-01-13 Thread Steven Champeon

on Wed, Jan 12, 2005 at 04:51:34PM -0800, william(at)elan.net wrote:

...a very long and useful and informative message, for which I thank him.

Off to go decipher the madness that is RFC3982,
Steve

-- 
hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com
join us!   http://hesketh.com/about/careers/account_manager.htmljoin us!


Re: [eweek article] Window of anonymity when domain exists, whois not updated yet

2005-01-12 Thread Michael . Dillon

= seriously, there have been various proposals ([ADV],
 etc) to facilitate legit UCE, but that hasn't slowed
 the arms race.  How would you recommend that we make
 it easier for legit businesses?

I don't propose that we make it easier for legit UCE.
I'm simply pointing out that it's an arms race because
we are solving the wrong problem. We are making it hard 
for people to send spam, therefore we are reaching the
point where only criminals do so. 

I would rather see us focus on securing the email 
architecture. Secure submission is part of that, but
for some reason people are unwilling to imagine an email
system in which an ISP will only accept incoming messages
from another ISP with which they have an existing
agreement, i.e. rather like email peering.

I happen to believe that a web of email peering
agreements is the best way to get us to the point
where it is difficult for anyone to anonymously 
send email because they *MUST* relay it through
an ISP who will not accept the email for relay
unless they have authenticated the user.

This is solving a different problem. Spam is merely
a symptom of an overly simplistic and insecure
email architecture. Now that it has drawn our
attention to the problem, I think we should
ignore spam and focus on making a better email
architecture that people can actually use again.

--Michael Dillon



Re: [eweek article] Window of anonymity when domain exists, whois not updated yet

2005-01-12 Thread Niels Bakker

* [EMAIL PROTECTED] ([EMAIL PROTECTED]) [Wed 12 Jan 2005, 12:23 CET]:
[..]
 for some reason people are unwilling to imagine an email
 system in which an ISP will only accept incoming messages
 from another ISP with which they have an existing
 agreement, i.e. rather like email peering.

You say this as if it's surprising that people are willing to accept
communications from people they have not yet communicated with before.

The world is not like your gated community.


-- Niels.

-- 
  The idle mind is the devil's playground


Re: [eweek article] Window of anonymity when domain exists, whois not updated yet

2005-01-12 Thread Suresh Ramasubramanian

On Wed, 12 Jan 2005 11:23:42 +, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
 I would rather see us focus on securing the email
 architecture. Secure submission is part of that, but
 for some reason people are unwilling to imagine an email
 system in which an ISP will only accept incoming messages
 from another ISP with which they have an existing
 agreement, i.e. rather like email peering.

Ah right - let's go right back to the days of X-400 or possibly UUCP nodes

Or if this is something newer, well, that's yet another proposal to
take to the IETF

 This is solving a different problem. Spam is merely
 a symptom of an overly simplistic and insecure
 email architecture. Now that it has drawn our

Changing the smtp protocol, or deploying an entirely new protocol that
meets your rigid critieria are some things you have got to do then ..
keeping in mind Vern Schryver's checklist of whether this is yet
another final ultimate solution to the spam problem -
http://www.rhyolite.com/anti-spam/you-might-be.html

-- 
Suresh Ramasubramanian ([EMAIL PROTECTED])


Re: [eweek article] Window of anonymity when domain exists, whois not updated yet

2005-01-12 Thread Michael . Dillon

 Ah right - let's go right back to the days of X-400 or possibly UUCP 
nodes

I don't want to rejuvenate an old obsolete protocol.

 Or if this is something newer, well, that's yet another proposal to
 take to the IETF

I don't want to develop a new protocol.

  This is solving a different problem. Spam is merely
  a symptom of an overly simplistic and insecure
  email architecture. Now that it has drawn our
 
 Changing the smtp protocol, or deploying an entirely new protocol that
 meets your rigid critieria are some things you have got to do then ..
 keeping in mind Vern Schryver's checklist of whether this is yet
 another final ultimate solution to the spam problem -
 http://www.rhyolite.com/anti-spam/you-might-be.html

I don't want to solve the spam problem so I don't
consider that Vern's criteria applies to my suggestion.
I suspect that my suggestion will make it easier to
track down spammers, and provide additional tools to
rate limit spam however I don't really care about
whether or not my suggestion stops spam.

I think that a secure email infrastructure is a good
thing to have, in and of itself. By secure, I mean
one in which messages get to their destination reliably,
i.e. not lost in some spam filter, and one in which
a recipient can reliably know where the message came
from if they feel the need to track down the sender by
other means.

My suggestion is to use the existing email protocols but
to make some operational changes in the way in which
we use them. Mail peering is an operational change, not
a protocol change. Forcing people to relay all email 
through their ISP's mail system is an operational change.
Refusing to accept any incoming email that is not relayed
by a mail peer is an operational change.

Recently in London, the police decided to tackle the drug
problem without making new laws. They implemented an operational
change by ceasing to arrest people (in most cases) for smoking
marijuana. They simply confiscate the drugs, warn them and walk
away. As a result, they freed up a large number of police resources
to focus on heroin and crack dealers.

In a sense, I am suggesting a similar reallocation of resources.
Rather than put those resources into filtering spam, I'd suggest
that we will get a better result by shifting the resources into
mail relaying and managing mail peering agreements. The spam will
continue but users will move to using the secure mail architecture
and won't see most of it. When the spammers also shift, there will
be more tools to track them down or shut them down or simply to rate
limit them.

--Michael Dillon



Re: [eweek article] Window of anonymity when domain exists, whois not updated yet

2005-01-12 Thread Niels Bakker

 for some reason people are unwilling to imagine an email
 system in which an ISP will only accept incoming messages
 from another ISP with which they have an existing
 agreement, i.e. rather like email peering.
 
 You say this as if it's surprising that people are willing to accept
 communications from people they have not yet communicated with before.
 
 There is a difference between an ISP and a person
 who sends or receives email. I am only suggesting
 that ISPs should make mail peering agreements,
 not individuals. When I wrote a weekly column for
[..]

What if I'm not an ISP but want to limit the amount of third parties
that are involved in delivery of e-mail between me and my friends?

What if I'm one of http://www.vix.com/personalcolo/ ?  To whom would I
have to give what favours in order to be part of your mail cabal so I
can communicate with people of different technical aptitudes?


 The world is not like your gated community.
 I have never lived in a gated community. Also, this
 new email architecture would not be a gated community.
 It may start off as a special service offered by a few
 larger ISPs to business clients, but over time I think
 most people will migrate to it.

(You sound like Dr. Strangelove.  That is a bad sign.)

Right now I have freedom of communication.  In your vision I would hand
all that over to my ISP for the benefit of giving complete control over
who can communicate with me to them.  Why exactly do you think that
would constitute a good deal for me?


-- Niels.

-- 
  The idle mind is the devil's playground


fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)

2005-01-12 Thread Steven Champeon

on Wed, Jan 12, 2005 at 01:52:43PM +, [EMAIL PROTECTED] wrote:
 I think that a secure email infrastructure is a good thing to have, in
 and of itself. By secure, I mean one in which messages get to their
 destination reliably, i.e. not lost in some spam filter, and one in
 which a recipient can reliably know where the message came from if
 they feel the need to track down the sender by other means.
 
snip

 In a sense, I am suggesting a similar reallocation of resources.
 Rather than put those resources into filtering spam, I'd suggest that
 we will get a better result by shifting the resources into mail
 relaying and managing mail peering agreements. The spam will continue
 but users will move to using the secure mail architecture and won't
 see most of it. When the spammers also shift, there will be more tools
 to track them down or shut them down or simply to rate limit them.

OK, sounds great. Let's start by making a few SHOULDs and MAYs into
MUSTs. Some of the following could be accomplished in a few hours, some
are probably not fixable unless we can reallocate some of the trillions
of hours we waste fighting spam to the problem AND get some political
support for accomplishing them (such as fixing whois once and for all).

Bear in mind that fixing email largely means fixing all the other
brokenness that allows people to take advantage of email's trust model.
So, then, it means fixing DNS conventions, abuse reporting support
infrastructure (starting with whois), and broken mail server/client
configurations.

0) for the love of God, Montresor, just block port 25 outbound already.

1) any legitimate mail source MUST have valid, functioning, non-generic
   rDNS indicating that it is a mail server or source. (Most do, many do
   not. There is NO reason why not.) Corollary: any NONlegitimate mail
   source SHOULD be labeled as such (e.g., 1.2.3.4.dynamic.example.net
   or 4.3.2.1.dhcp.resnet.foo.edu)

2) any legitimate mail source MUST HELO/EHLO with its own valid Internet
   hostname, not foo.local or SHIZNITSONY26354 or exchng1. Or,
   with their own bracketed IP. (Most do, many do not. There are very
   few valid reasons why not. Broken software should be fixed.)

3) any legitimate mail source MUST be in a domain with functioning abuse
   and postmaster mailboxes, which MUST also be listed in the whois db
   entry for both that domain and IP space corresponding to the mail
   source. (Not difficult to do at all.)

4) all domains with invalid whois data MUST be deactivated (not
   confiscated, just temporarily removed from the root dbs) immediately
   and their owners contacted. (NOTE: this will require fixing .org,
   among others whose public whois output is stale and not easily
   fixable via certain registrars). (Would probably take the most
   effort, but given a properly broad window of notification should be
   possible.)

5) whois data MUST be normalized and available in machine-readable form
   (such as a standard XML schema) - the I hate spam so I use a bogus
   contact addy excuse will be obsolete, as email infrastructure will
   be secured, right? (Honestly, how hard would this be? Gather up all
   the now-extremely varied formats, compromise on a superset, and map.
   Then put it all on a Web site or a reliable, distributed
   infrastructure. I'm REALLY TIRED of getting whois.$foo:111
   connection refused when I'm trying to track down a spammer's support
   network).

6) all mail clients MUST support SMTP AUTH and the MSA port. (Many do.)
   All mail servers MUST support SMTP AUTH and the MSA port. (Some do.)

7) all ISPs MUST act on ANY single abuse report (including being
   informed of infected customer machines, which MUST be removed from
   the Internet ASAP. No excuses) (Halve unemployment today. Retrain
   textile and manufacturing workers. Outsource the entire job. I don't
   care. Go read broken windows theory.)

8) all mail server, antivirus, and antispam software MUST NOT accept and
   then bounce (to the usually forged sender) bogus warnings or DSNs.
   (A chicken/egg problem, really, but some systems have NO excuse -
   such as A/V systems that helpfully inform me that some virus that
   ALWAYS forges the sender did so in a message sent from a system I
   have no control over.)

9) all mail servers and webmail systems, etc. MUST properly include
   tracking information in their Received: headers. (You might be
   surprised how many webmail systems and large ISPs fail this one.
   It's largely how 419/AFF scams are propogated.)

10) all HTML display engines MUST fix the bugs that allow for a
   link to say, 'phish.randomisp.net.br' appear as 'wamu.com'
   (Social engineering, but important in this day of hostile JPG
   images.)

That should do it. I'd also ask that HTML email simply vanish, since I'm
clearly already rubbing this lamp down to its bitter metal core... ;) 

-- 
hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com
join us!   

Re: [eweek article] Window of anonymity when domain exists, whois not updated yet

2005-01-12 Thread Michael . Dillon

 Right now I have freedom of communication.  In your vision I would hand
 all that over to my ISP for the benefit of giving complete control over
 who can communicate with me to them. 

Perhaps you could explain to me just how you
currently manage to get port 25 packets delivered
to your friends without transitting your ISP?
Or did you just mean freedom of communication
in a rhetorical sense?

And if you will trust an ISP to deliver port 25
packets then why wouldn't you trust them to
deliver email messages?

--Michael Dillon



Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)

2005-01-12 Thread Chris Adams

Once upon a time, Steven Champeon [EMAIL PROTECTED] said:
 7) all ISPs MUST act on ANY single abuse report (including being
informed of infected customer machines, which MUST be removed from
the Internet ASAP. No excuses)

One problem I have with this one is people do forge reports, and there
is no way around that.  Also, as long as there are networks that don't
enforce source address filtering, port probing complaints cannot be
validated (I take them as valid unless proven otherwise, but we have had
a few that appear after the fact to be forged and/or spoofed).  If you
_always_ take someone off-line on a single complaint, you make it easy
for someone to get someone else kicked off.

-- 
Chris Adams [EMAIL PROTECTED]
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.


Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)

2005-01-12 Thread Steven Champeon

on Wed, Jan 12, 2005 at 10:32:13AM -0600, Chris Adams wrote:
 
 Once upon a time, Steven Champeon [EMAIL PROTECTED] said:
  7) all ISPs MUST act on ANY single abuse report (including being
 informed of infected customer machines, which MUST be removed from
 the Internet ASAP. No excuses)
 
 One problem I have with this one is people do forge reports, and there
 is no way around that.  Also, as long as there are networks that don't
 enforce source address filtering, port probing complaints cannot be
 validated (I take them as valid unless proven otherwise, but we have had
 a few that appear after the fact to be forged and/or spoofed).  If you
 _always_ take someone off-line on a single complaint, you make it easy
 for someone to get someone else kicked off.

Think of it as two separate requirements, one dependent on the other.
1) I'm tired of hearing stories about ISPs who let Spammer X continue
because there weren't enough complaints, and 2) once you've verified
that a reported infected host IS infected, take 'im offline ASAP.

Or, restate it as no more abuse desk role account autoack ignorebots.

-- 
hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com
join us!   http://hesketh.com/about/careers/account_manager.htmljoin us!


Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)

2005-01-12 Thread Eric Brunner-Williams in Portland Maine

 4) all domains with invalid whois data MUST be deactivated (not
confiscated, just temporarily removed ...

All? Even those unpublished and therefore non-resolving? Sensible for the
scoped-to-totality trademarks weenies who argue that the stringspace is a
venue for dilution, whether the registry publishes all of its allocations
or not.

I'm not sure why anyone cares about a very large class of domains in the
context of SMTP however. 

 5) whois data MUST be normalized and available in machine-readable form

There are some registries that use paper to answer registration queries.

I'm not sure why anyone cares about a very small class of domains in the
context of SMTP however. 

Aggregation and reformatting have their place. We explored this in the
whoisfix bofs but no working group congealed around fixing :43.

Again, I'm not sure why anyone cares about a very large class of whois:43
output sources in the context of SMTP however. 

Eric




Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)

2005-01-12 Thread Steven Champeon

on Wed, Jan 12, 2005 at 12:55:06PM +, Eric Brunner-Williams in Portland 
Maine wrote:
  4) all domains with invalid whois data MUST be deactivated (not
 confiscated, just temporarily removed ...
 
 All? Even those unpublished and therefore non-resolving? Sensible for the
 scoped-to-totality trademarks weenies who argue that the stringspace is a
 venue for dilution, whether the registry publishes all of its allocations
 or not.

Why would it matter if you deactivated an unpublished/non-resolving domain?
If you care about the domain, keep the whois data up to date and accurate.
 
 I'm not sure why anyone cares about a very large class of domains in the
 context of SMTP however. 

For one thing, a very large class of domains are being used as
throwaways by spammers, who use them up at a rate approaching 1 every
six hours for some of them, after which they are abandoned. In the
meantime, their whois info is inaccurate or (thanks, VRSN!) not yet
published, anyway, so the criminals can hide behind the fact that nobody
seems to care about whether whois is accurate. This destroys any
potential protection value whois might offer, and allows spammers and
other abusers to fly below the radar, accountable to nobody.
 
  5) whois data MUST be normalized and available in machine-readable form
 
 There are some registries that use paper to answer registration queries.

And?
 
 I'm not sure why anyone cares about a very small class of domains in the
 context of SMTP however. 

It's not a very small class of domains with more or less unpredictable
data formats. It's ALL of them, or damn near. I should be able to write
a program, relatively easily, that would give me any available contact
or registrant information on a per-field basis, from any whois service.
The wide variety and nonuniformity of the existing services makes that
task daunting at best; that the information is likely wrong or stale is
enough to undermine whatever faith we might have had in it once.
 
 Aggregation and reformatting have their place. We explored this in the
 whoisfix bofs but no working group congealed around fixing :43.

What were the objections/sticking points? 
 
 Again, I'm not sure why anyone cares about a very large class of whois:43
 output sources in the context of SMTP however. 

It's not just the context of SMTP. It's the context of accountability on
the Internet, which bad actors are exploiting, currently, via SMTP.

I really do think it would benefit some folks here to read up on the
broken windows theory of crime prevention. The majority of the 'Net
is looking more and more like a warehouse full of broken windows (no,
this isn't a deliberate pun on the OS) and it's no surprise that we
waste many billions of dollars a year as a result.

Let people get away with petty crimes, and they get the message loud and
clear that you probably don't care about the big crimes, either - while
giving them a great opportunity to perform those crimes in an atmosphere
of an almost complete lack of accountability.

-- 
hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com
join us!   http://hesketh.com/about/careers/account_manager.htmljoin us!


Re: [eweek article] Window of anonymity when domain exists, whois not updated yet

2005-01-12 Thread Niels Bakker

 Right now I have freedom of communication.  In your vision I would hand
 all that over to my ISP for the benefit of giving complete control over
 who can communicate with me to them. 
 Perhaps you could explain to me just how you
 currently manage to get port 25 packets delivered
 to your friends without transitting your ISP?
 Or did you just mean freedom of communication
 in a rhetorical sense?

Because it's not hitting the disks in their mail spool, nor are the
sender and receiver checked against any policy databases.


 And if you will trust an ISP to deliver port 25
 packets then why wouldn't you trust them to
 deliver email messages?

Because the packets are an order of magnitude easier to do than e-mail,
and the orders only keep rising when the number of subscriber rises.

IP service is ubiquitous, your proposal would make an important service
running on top of it not anymore.


-- Niels.

-- 
  The idle mind is the devil's playground


Re: [eweek article] Window of anonymity when domain exists, whois not updated yet

2005-01-12 Thread Owen DeLong
Michael,
	Whether you like it or not, SPAM is the problem.  There are legitimate
uses of anonymous email.  I, for one, think that a web of mail peering
agreements would be detrimental to the situation, not helpful.  Yes, people
should have the option of authenticating emails they send, and, end users
should have the option of rejecting unauthenticated messages.  That's all
there today.  There's still lots of work to do on the UI and many 
improvements
to be made in the smooth interoperation of the various standards, but,
the base capabilities exist.

As an example, I run a mail server for a number of non-profit
organizations.  I do this for free.  It runs on the mailserver I maintain
for my household.  I'm able to do that because I'm not having to pay
someone for an email peering agreement, but, instead, am able to deliver
messages directly to the MX of the receiving party.
Do you really think we need SMBGP?  I think not.
Owen


pgpYtbwcTFtYB.pgp
Description: PGP signature


Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)

2005-01-12 Thread Adi Linden

 0) for the love of God, Montresor, just block port 25 outbound already.

What is wrong with dedicating port 25 to server to server communication
with some means of authentication (DNS?) to ensure that it is indeed a
vaild mail server. Mail clients should be using port 587 to submit
messages to their local MTA.

Adi


Re: [eweek article] Window of anonymity when domain exists, whois not updated yet

2005-01-12 Thread Owen DeLong

--On Wednesday, January 12, 2005 4:11 PM + [EMAIL PROTECTED] 
wrote:


Right now I have freedom of communication.  In your vision I would hand
all that over to my ISP for the benefit of giving complete control over
who can communicate with me to them.
Perhaps you could explain to me just how you
currently manage to get port 25 packets delivered
to your friends without transitting your ISP?
Or did you just mean freedom of communication
in a rhetorical sense?
Yes, my port 25 packets go through my ISP.  However, TLS means that none
of the SMTP conversation between my mailserver and my friends mailserver
is visible to my ISP in an unencrypted form.  Your system would require
me to expose at least the envelope information to my ISP.  Do you see
the difference here?
And if you will trust an ISP to deliver port 25
packets then why wouldn't you trust them to
deliver email messages?
I don't trust them to deliver port 25 packets.  I expect them to deliver
port 25 packets.  Then, I authenticate the system at the other end using
TLS and have an encrypted coversation.  My ISP can see that there's
encrypted data going through their network between our servers, but,
they (at least theoretically) can't see what that data is.
Owen

--
If it wasn't crypto-signed, it probably didn't come from me.


pgpfaThFsltuT.pgp
Description: PGP signature


Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)

2005-01-12 Thread Steven Champeon

on Wed, Jan 12, 2005 at 01:49:53PM +, Eric Brunner-Williams in Portland 
Maine wrote:
 
  Why would it matter if you deactivated an unpublished/non-resolving domain?
 
 How do you deactivate an unpublished/non-resolving domain? You may borrow
 a registrar or registry hat if that is useful to answer the question.

I suppose it depends on how you define 'unpublished'; and how you define
'non-resolving'.

A year and a half ago, I was subjected to a joe job by Brian Westby (the
bounces stopped the day after the FCC fined him), using several domains,
among them adultwebpasshosting.org. It had been registered, was in whois
with obviously forged data, resolved to an IP, and I reported it to
ICANN for having invalid whois data. It took them, as near as I can tell
(I was never notified of the action taken) at least a year to have it
removed from the root dbs.

I'd like to avoid going through that nonsense again.
 
  If you care about the domain, keep the whois data up to date and accurate.
 
 That is the policy articulated by the trademarks stakeholders in the ICANN
 drama, but how does their policy, which is indifferent to any condition but
 strindspace allocation, relate to any infrastructure that has one or more
 additional constraints?

Please see my other message. Allowing domains with invalid whois data to
remain in use facilitates abuse in other realms.
 
   I'm not sure why anyone cares about a very large class of domains in the
   context of SMTP however. 
  
  For one thing, a very large class of domains are being used as
  throwaways by spammers ...
 
 Do you know anything about the acquisition pattern at all, or if there is
 any useful characterization finer in scope than all?

One of the domains we host has been the victim of an ongoing joe job. The
sender forges an address in the domain for the SMTP MAIL FROM: and when
the message(s) bounce(s), we get the DSN(s). I've got bounce messages here
going back several months. In the past month (since Dec 1), I've seen (not
counting the tens of thousands of DSNs I've refused from idiot outscatter
hosts):

count domainreceived
registered  diff
- ---   --  --- 
   13 kakegawasaki.com  Jan  6 2005 Dec 23 2004 
14d
7 oertlika.com  Jan  7 2005 no 
whois info   n/a
6 mikejensen.info   Dec 30 2004 Dec  9 2004 
21d
5 kristinaficci.infoJan  8 2005 Dec 22 2004 
17d
4 rhianjonesmuchos.com  Jan 10 2005 no whois info   
n/a
4 krauszolts.info   Jan  7 2005 Dec 22 2004 
16d
4 gregbryant.info   Dec 31 2004 Dec  9 2004 
22d
4 elitke.info   Dec  1 2004 Nov 28 
2004  3d
3 tlepolemosmilos.com   Jan  9 2004 no whois info   
n/a
3 latvianet.infoDec 25 2004 Dec  3 2004 
22d
3 judsononly.info   Dec 30 2004 Dec 12 2004 
18d
2 tarumisalata.info Dec 28 2004 Dec 12 2004 
16d
2 sawawer.net   Dec 13 2004 no 
whois info   n/a
2 sakkama.info  Dec 15 2004 Dec  3 
2004 12d
2 purkyne.info  Dec  9 2004 Nov 28 
2004 11d
2 kazoplace.com Dec 31 2004 no 
whois info   n/a
2 katrianne.infoDec  1 2004 Nov 28 2004 
 3d
2 heinrichkayser.info   Dec 30 2004 Dec  9 2004 
21d
2 cavaradossi.net   Dec 23 2004 no whois info   
n/a
2 brangane.info Jan  3 2005 Dec 18 
2004 16d
1 wurmhug.com   Jan  1 2005 no 
whois info   n/a
1 ulissedinires.com Dec 24 2004 Nov 11 2004 
13d
1 onlycomello.info  Dec 19 2004 Dec  3 2004 
16d
1 mysalpetriere.com Dec 26 2004 Dec 23 2004 
 3d
1 konstitutsiya.com Dec 17 2004 Dec  3 2004 
14d
1 eugenisisplace.info   Dec 27 2004 Dec 12 2004 
15d

Very few of these sighted span more than an 18 hour period between first
and last appearance in a bounce. 

All those I've tested simply redirect to some porn site or other; for
a list from November, see below:

domain  redirects to

Re: [eweek article] Window of anonymity when domain exists, whois not updated yet

2005-01-12 Thread Steven Champeon

on Wed, Jan 12, 2005 at 10:18:30AM -0800, Owen DeLong wrote:
 Michael,
   Whether you like it or not, SPAM is the problem.

SPAM is a luncheon meat. UCE is one of the many problems, among the
others being viruses/worms/trojans and their traffic (easily blocked by
the proper upstream authority), outscatter/backscatter traffic
(whether responding to joe jobs, viruses, or spammers trying to send
their crud to virus-generated bogus addresses, etc.), bogus reports
of forgery (cf. [EMAIL PROTECTED], for one example), C/R systems, 
autoresponders,
callback mechanisms, et cetera. 

-- 
hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com
join us!   http://hesketh.com/about/careers/account_manager.htmljoin us!


Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)

2005-01-12 Thread Steven Champeon

on Wed, Jan 12, 2005 at 12:41:44PM -0600, Adi Linden wrote:
  0) for the love of God, Montresor, just block port 25 outbound already.
 
 What is wrong with dedicating port 25 to server to server communication
 with some means of authentication (DNS?) to ensure that it is indeed a
 vaild mail server.

Nothing at all. That's more or less what I proposed, though I'd prefer
to see something TODAY, like the easily implemented rDNS fix, rather
than wait any longer for SPF/DomainKeys/etc. to go through a zillion
rounds of argument. As it stands, I reject a rather large percentage of
the spam delivery attempts here using generic rDNS as a basis. (Either
in the rDNS of the connecting host itself or in the HELO; the latter is
responsible for ~75%-80% of the rejections, assumed to be almost
entirely zombie-originated).

 Mail clients should be using port 587 to submit messages to their
 local MTA.

Agreed.

-- 
hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com
join us!   http://hesketh.com/about/careers/account_manager.htmljoin us!


Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)

2005-01-12 Thread Eric Brunner-Williams in Portland Maine

 Numerous (as in at least hundreds, probably more) of spam gangs are
 purchasing domains and burning through them in spam runs.  In many
 cases, there's a pattern to them; in others, if there's a pattern,
 it's not clear to me what it might be.

From my point of view, pattern is which registars are getting the buys,
for which registries, where the ns's are hosted, and for domains used in
the return value side, hosting details. The latter to reduce to RIR CIDRs.

There is more, but that is the first cut, localization of registrar(s) and
registries and CIDRs.

 This bunch prefers domains in .info -- no doubt motivated in part by things
 like the recent $1.95 sale on such domains.  

OK. Now you've identified price as a significant control variable. There are
registrars that don't sell .info. I don't. There are registars that don't
sell to directly to registrants. I can think of half a dozen of us who only
sell to corporations and bonafide people who buy reasonable names.

Transcendental numbers in decimal character form are reasonable. Your
two example sets are not reasonable.

 The dirty little secret is that all this activity on the part of spammers
 is a gold mine for registrars.

This isn't going to make me think you can add or subtract.

 It's gotten so bad that -- to a darn good first approximation -- if you
 find a domain in the .biz or .info TLDs

I agree, and don't sell .biz, .info or .name, or .cc or .tv or .bz or any
of the obvious repurposed cctlds, with the exception of my friend Bill
Semich's .nu, which actually means something in Sweden for local reasons.
I do plan to sell .aero, .coop and .museum, however.

In case it is inobvious, there is a possibility that part of _your_
problem (and a big part of my problems) can be placed at the figurative
door of a 501(c)(3) located in California.

 The answer? (1) no obfuscated registrations (2) mass, fast, permanent
 confiscation of spammer domains (3) requirement for reasonably correct
 domain registration info ... and (4) publication of all WHOIS data in
 a simple, easily parseable form  ...

Nothing in this laundry list that makes the cost of bad business for my
competitors rise, see add and subtract, above.

Try the following: 1,$s/registrars/isp/g and 1,$s/registry/rir/g, and
1,$s/domain/ipv4_addr/. If you're still keen on your approach, then it
might be a good one.

I've replied after removing your personal identifiers back to NANOG.
I appreciate the data, but I want the discourse to be multicast.

Eric


Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)

2005-01-12 Thread Eric Brunner-Williams in Portland Maine

 I suppose it depends on how you define 'unpublished'; and how you define
 'non-resolving'.

Your opening remark was that policy foo must be applied to all domains.

This doesn't accomplish anything for the set of domains that will never
be published (registry reserved strings), nor those that absent seperate
acts of malfesance, will always have a very low average association with 
disfunction -- the 50% of the .net namespace that actually goes to real
boxen owned and operated by real people.

Between, and in addition to these two samples, there are classes of domains
that are vastly less likely to be used in uce and equivalent schemes. The
class of domains purchased simply to take them out, such as Hamming distance
buys around a defended mark, may never resolve.

All is too blunt a tool.

 I reported it to ICANN for having invalid whois data. It took them ...
 ... a year to have it removed from the root dbs.

That is an ICANN issue. It may come as a surprise to you but for the past
few years the ISP Constituency has ceased to exist, and has been folded
into Marilyn Cade and Philipe Sheppard's Business Constituency.

 Please see my other message. Allowing domains with invalid whois data to
 remain in use facilitates abuse in other realms.

If it isn't fixing insecure email infrastructure, then it needs to find
a thread and/or list of its own.

The little table of domain names and redirects is slightly useful, but it
would be more useful if your data could show registrar clustering. 

 I'd be delighted if you have pointers to a paid whois reformatter, but
 I still believe strongly that it should not be necessary.

The quality of data usually has a relationship with the cost of care
that has gone into that data, just like abuse desks.

Eric


Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)

2005-01-12 Thread Steven Champeon

on Wed, Jan 12, 2005 at 05:28:45PM +, Eric Brunner-Williams in Portland 
Maine wrote:
 All is too blunt a tool.

So, then, when registering a domain, there should be a little checkbox
saying I intend to abuse the Internet with this domain? It makes no
sense to have a universal policy if it is not universally enforced. Why
is it considered such a crazy proposition that domains should have valid
and correct whois data associated with them?
 
  Please see my other message. Allowing domains with invalid whois data to
  remain in use facilitates abuse in other realms.
 
 If it isn't fixing insecure email infrastructure, then it needs to find
 a thread and/or list of its own.

Bah. You're saying that you're uninterested in discussing the root causes
that allow and even encourage abuse to occur in specific realms. I guess
you're not interested in actually fixing insecure email infrastructure.
 
 The little table of domain names and redirects is slightly useful, but it
 would be more useful if your data could show registrar clustering. 

Why should this matter? Spammy can always choose a different registrar
every day. So what? He is registering domains for use in abusive and
criminal acts, and the message I'm getting from you is that it should
only be of concern to you if he uses the same registrar?
 
-- 
hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com
join us!   http://hesketh.com/about/careers/account_manager.htmljoin us!


Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)

2005-01-12 Thread Eric Brunner-Williams in Portland Maine

 Why is it considered such a crazy proposition that domains should have
 valid and correct whois data associated with them?

There is no relationship between data and funcion. The data is not
necessary to implement function-based policy.

 Bah. You're saying that you're uninterested in discussing the root causes
 that allow and even encourage abuse to occur in specific realms. I guess
 you're not interested in actually fixing insecure email infrastructure.

I have no idea what specific realms you could be referring to.

 The little table of domain names and redirects is slightly useful, but it
 would be more useful if your data could show registrar clustering. 

 Why should this matter? Spammy can always choose a different registrar
 every day. So what? He is registering domains for use in abusive and
 criminal acts, and the message I'm getting from you is that it should
 only be of concern to you if he uses the same registrar?

OK. The choice of registrar, registrar policy, registrar price, and so on
isn't data that could be of use to anyone ever.

But you're going to get valid and correct whois data from all registrars.

How will you get that? What does valid and correct mean? Does it apply
to all the records in a single domain registration, or just some of them?

Eric


Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)

2005-01-12 Thread Steven Champeon

on Wed, Jan 12, 2005 at 04:24:42PM +, Eric Brunner-Williams in Portland 
Maine wrote:
(quoting Anonymous): 
  Numerous (as in at least hundreds, probably more) of spam gangs are
  purchasing domains and burning through them in spam runs.  In many
  cases, there's a pattern to them; in others, if there's a pattern,
  it's not clear to me what it might be.
 
 From my point of view, pattern is which registars are getting the buys,
 for which registries, where the ns's are hosted, and for domains used in
 the return value side, hosting details. The latter to reduce to RIR CIDRs.

I provided the IPs to which all of the latter domains resolved at the
time I checked. All went to four IPs, all in China, three in the same
network. The nameservers exhibit similar behavior, though often also
with Brazilian nameservers along with Chinese. Not in the last month, tho:

nameservers:
   16 ns1.anwoo.com   202.67.231.145   HKNET-HK
   14 ns1.eslom.com   61.128.196.155   CHINANET-CQ
   12 ns1.epoboy.com  222.51.91.226CRTC
   12 ns1.bomofo.com  221.5.250.122CNCGROUP-CQ
4 ns1.lenpo.com   207.234.224.202  AFFINITY-207-234-128-0
4 ns1.boozt.com   218.7.120.81 JINDU-COMPUTER-NET-COM
2 ns1.mynameserver.ca 202.67.231.145   HKNET-HK

registrars by whois server:
   15 whois.afilias.info
3 whois.planetdomain.com
2 whois.godaddy.com
2 whois.domainzoo.com
1 whois.registrationtek.com
1 whois.joker.com

So? Of course .info is handled by afilias. Sponsoring registrars for
.info domains mentioned upthread:
9 R126-LRMS  - Enom
4 R239-LRMS  - Primus
2 R171-LRMS  - GoDaddy

There's your clustering. Feel free to somehow reduce these to CIDRs or
ASNs; they're not used in the message headers anyway, so all you can do
is block the redirection for your users, but not prevent them from being
deluged with the spam itself, nor prevent me and others from being deluged
with the bogus DSNs. 

So what? Eventually, better antispam techniques will lead to the ability
to block messages from or referencing domains with banned nameservers.

And then spammy will set things up so that he has a new nameserver for
every run. And we'll still have insecure email, because he'll have
continued to get away with it, because he can hide behind private
whois for his domains registrations, he'll continue to burn through the
net namespace leaving nothing but scorched earth, and none of the
underlying conditions will have been addressed.

It's no longer a simple matter of blocking the sender origin, botnets
have taken care of that. It's no longer a matter of blocking known spammy
domains in SMTP envelopes; they're forging them. It's not a matter of
blocking mail with known spammy domains in it, as these are one-a-day
throwaway redirectors. It's not a matter of blocking mail with domains
that point to rogue nameservers, ASNs, or CIDRs, spammy can register new
domains and use new ones every day. It's not a matter of any of these
things, though I use them all, and with some effect.

The problem is that spammy is getting away with this by modifying his
tactics slightly and keeping a step ahead of the game, and because few
understand or care about actually /fixing the underlying brokenness/
that lets him get away with it day after day.

 There is more, but that is the first cut, localization of registrar(s) and
 registries and CIDRs.

I fail to see how isolating registrations to a single registrar changes
the facts on the ground - if anything, you're already showing that you
are at least one step behind Spammy, by making this a requirement. Or,
alternately, you're simply saying that those who care about net abuse are
shackled by ICANN's bylaws and therefore we can do nothing.

-- 
hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com
join us!   http://hesketh.com/about/careers/account_manager.htmljoin us!


Re: [eweek article] Window of anonymity when domain exists, whois not updated yet

2005-01-12 Thread Valdis . Kletnieks
On Wed, 12 Jan 2005 11:23:42 GMT, [EMAIL PROTECTED] said:

 I happen to believe that a web of email peering
 agreements is the best way to get us to the point
 where it is difficult for anyone to anonymously 
 send email because they *MUST* relay it through
 an ISP who will not accept the email for relay
 unless they have authenticated the user.

The X.400 concepts of ADMD= and PRMD= really caught on, didn't they? ;)

Peering in a world of 64K ASNs, mostly basically static, is a lot different
than peering in a world of 40 million plus .COMs, many in motion.  Most of
the time, we're lucky if the MX record points to the right place



pgpwt3dX4b1iJ.pgp
Description: PGP signature


Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)

2005-01-12 Thread Eric Brunner-Williams in Portland Maine

Taking your comment in reverse order.

 Or, alternately, you're simply saying that those who care about net
 abuse are shackled by ICANN's bylaws and therefore we can do nothing.

I don't think you have a monopoly on care (or clue) about net abuse,
but it is pretty clear that you're not tall enough to ride the ICANN
roller coaster.

Thus far, all you've done is recycle the policy claim of the trademarks
interests, a highly effective stakeholder and rational entity within
ICANN, and the policy claim of the law enforcement interests, typically
American, and not an organic ICANN stakeholder, and neither effective
nor rational within ICANN (personal opinion, from the first FBI/LE UWHOIS
meeting, March 2000 WDC if memory serves, to the present).

Now why should that catch your attention? How about because neither of
these policy authors (good, bad or simply ugly) care particularly about
SMTP, in fact, the trademark policy author doesn't know that SMTP exists,
because the use of trademarks in SMTP envelopes or bodies has not been
argued (yet) to support a dilution claim. As the FBI/LE goal set isn't
coherent or rational I'm going to assign it a protocol independent end
point identifier goal, because I don't think the FBI/LE goal set is as
limited as SMTP.

This thread however is about SMTP, and some glop that might make it
differently, or less insecure.

So, if your primary policy tool is the same policy tool used by actors
seeking ends indifferent to yours, either you are lucky or you are wrong.

Now, is ICANN part of the problem space? It is for me, but I'm trying
to compete with entrenched monopoly in the registry space that has the
single greatest control over domain name policy, and entrenched cartel
in the registrar space, and no technical issue, not secure operation of
the root zone servers, correctness of the gtld zone servers, SLA metrics
for gtld registry systems, data escrow, etc., has displaced the trademark
position on whois:43 for the most important policy or operational issue
for that corporation. My competitors (measured by market share) are for
the most part indifferent to spam, porn, and social policy generally.

Is it for you? Apparently not. So just leaving the trademarks people in
charge should solve your problem in finite time. That means you may have
already won.

Eric


Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)

2005-01-12 Thread william(at)elan.net


On Wed, 12 Jan 2005, Steven Champeon wrote:

  In a sense, I am suggesting a similar reallocation of resources.
  Rather than put those resources into filtering spam, I'd suggest that
  we will get a better result by shifting the resources into mail
  relaying and managing mail peering agreements. The spam will continue
  but users will move to using the secure mail architecture and won't
  see most of it. When the spammers also shift, there will be more tools
  to track them down or shut them down or simply to rate limit them.
 
 OK, sounds great. Let's start by making a few SHOULDs and MAYs into
 MUSTs.

Its nearly impossible to make MAY into MUST. You can do slow update 
from MAY to SHOULD and from SHOULD to MUST over period of several
years but in that case you also need to provide exact date when old
SHOULD would be depreciated and until then you can't assume its a MUST.

 Some of the following could be accomplished in a few hours,
Ha. You're kidding, right?

 some are probably not fixable unless we can reallocate some of the 
 trillions of hours we waste fighting spam to the problem AND get some 
 political support for accomplishing them (such as fixing whois once and 
 for all).
Its being worked on and CRISP just released new whois standard (see below)
The migration is however a very slow process. 

 Bear in mind that fixing email largely means fixing all the other
 brokenness that allows people to take advantage of email's trust model.
I'd actually advocate for slow change in email infrastructure model.
But I'll not elaborate at this time, see you in 2 months about it.

 So, then, it means fixing DNS conventions, abuse reporting support
 infrastructure (starting with whois), and broken mail server/client
 configurations.
 
 0) for the love of God, Montresor, just block port 25 outbound already.

There are legitimate uses of port 25, the question is that you need to
have it blocked for anauthenticated use. There are the following ways
to accomodate situations when some users need to have unblocked por25
when majority do not:

1. Blocking port25 by default and allowing authenticated users who have
   requested it to have it unblocked. That should be done by means of 
   radius profile and I believe can be done with existing tools (I have
   not been involved in dialup for 4 years now but from what I remember
   I could easily have specific user profiles with different redirection
   data for port25).

2. Not blocking port25 by default but measuring all traffic that passes
   through (by that I mean just number of SMTP packets from each ip, not
   actually looking inside the packets). If any ip shows highier then
   normal usage then its temporarily blocked and ISP immediatly tries to
   contact the user to verify what they are not spamming. A complimentary
   to this is verification that source IPs are the ones assigned by ISP
   and not spoofed or IPs routed through vpn from some other place (see
   recent threads about, last one by Ejay when his dialup was abused).

Both of the above are ways are practical and can be implemented by ISPs
given enough interest.

 1) any legitimate mail source MUST have valid, functioning, non-generic
rDNS indicating that it is a mail server or source. (Most do, many do
not. There is NO reason why not.) Corollary: any NONlegitimate mail
source SHOULD be labeled as such (e.g., 1.2.3.4.dynamic.example.net
or 4.3.2.1.dhcp.resnet.foo.edu)

For UnifiedSPF I proposed before that special SPF record be published for 
the DNS hostname indicated by reverse dnsand that be checked to verify if
it should or should not be source of email for that ip. 
 
 2) any legitimate mail source MUST HELO/EHLO with its own valid Internet
hostname, not foo.local or SHIZNITSONY26354 or exchng1. Or,
with their own bracketed IP. (Most do, many do not. There are very
few valid reasons why not. Broken software should be fixed.)

RFC2821 says that HELO should be valid hostname, so a few things that
do happen right now are already against it. A new SPF draft also includes 
checking HELO which will essentially accomplish this in practice. 
CSV group is also advocating the same with different record syntax.
Again it would be slow process of migration from when we start using and 
have to discard badly configured named to when majority (and 99% of those 
sending email) have these records and we can begin to advocate for MUST.

 3) any legitimate mail source MUST be in a domain with functioning abuse
and postmaster mailboxes, which MUST also be listed in the whois db
entry for both that domain and IP space corresponding to the mail
source. (Not difficult to do at all.)

I beleive this is already in RFCs. Checking for this in real-time is 
somewhat impractical due to current whois system but we do have 
rfc-ignorant blacklist specifically for the reported bad whois domains.
 
 4) all domains with invalid whois data MUST be deactivated (not
confiscated, just 

Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)

2005-01-12 Thread Dave Crocker

On Wed, 12 Jan 2005 17:40:10 -0500, [EMAIL PROTECTED] wrote:
   1) any legitimate mail source MUST have valid, functioning, non-generic
  rDNS indicating that it is a mail server or source.

  And how, exactly, does it indicate it's a mail server or source?

In general, that's what dkeys/iim and csv (and maybe spf) are attempting to 
provide.


d/
--
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker  a t ...
WE'VE MOVED to:  www.bbiw.net



Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)

2005-01-12 Thread Valdis . Kletnieks
On Wed, 12 Jan 2005 19:19:24 PST, Dave Crocker said:
 On Wed, 12 Jan 2005 17:40:10 -0500, [EMAIL PROTECTED] wrote:
    1) any legitimate mail source MUST have valid, functioning, non-generic
   rDNS indicating that it is a mail server or source.
 
   And how, exactly, does it indicate it's a mail server or source?
 
 In general, that's what dkeys/iim and csv (and maybe spf) are attempting to 
 provide.

Yes, but he asked for a rDNS solution specifically...


pgpug8CN5S1d9.pgp
Description: PGP signature


Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)

2005-01-12 Thread Suresh Ramasubramanian

On Wed, 12 Jan 2005 23:19:47 -0500, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
 On Wed, 12 Jan 2005 19:19:24 PST, Dave Crocker said:
  In general, that's what dkeys/iim and csv (and maybe spf) are attempting to 
  provide.
 
 Yes, but he asked for a rDNS solution specifically...

I think Steve was referring to some things that can be implemented
right away, like if you operate a mailserver, please make sure that
it isn't on a host that has reverse dns like ppp-XXX.adsl.example.com,
try to give it unique and non generic rDNS, preferably with a hostname
that starts off with smtp-out, mail, mta etc)

Basically a call to operators to adopt a consistent forward and
reverse DNS naming pattern for their mailservers, static IP netblocks,
dynamic IP netblocks etc.

-- 
Suresh Ramasubramanian ([EMAIL PROTECTED])


Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)

2005-01-12 Thread Steven Champeon

on Thu, Jan 13, 2005 at 10:25:18AM +0530, Suresh Ramasubramanian wrote:
 On Wed, 12 Jan 2005 23:19:47 -0500, [EMAIL PROTECTED]
 [EMAIL PROTECTED] wrote:
  On Wed, 12 Jan 2005 19:19:24 PST, Dave Crocker said:
   In general, that's what dkeys/iim and csv (and maybe spf) are attempting 
   to provide.
  
  Yes, but he asked for a rDNS solution specifically...
 
 I think Steve was referring to some things that can be implemented
 right away, like if you operate a mailserver, please make sure that
 it isn't on a host that has reverse dns like ppp-XXX.adsl.example.com,
 try to give it unique and non generic rDNS, preferably with a hostname
 that starts off with smtp-out, mail, mta etc)

Yep. And it helps if the rDNS is right-anchored, (uses subdomains
to distinguish between various assignment types and technologies) a la

 1-2-3-4.dialup.dyn.example.net
   
 4-3-2-1.dsl.static.example.net
^^^
as opposed to 

 dyn-dialup-1-2-3-4.example.net
 static-dsl-4-3-2-1.example.net

as the former is easier to block using even the simplest of antispam
heuristics. I'd love to see a convention, or even a standard, arise for
rDNS naming of legit mail servers. But I'll happily settle for decent
and consistent rDNS naming of everything else ;)

 Basically a call to operators to adopt a consistent forward and
 reverse DNS naming pattern for their mailservers, static IP netblocks,
 dynamic IP netblocks etc.

...and to ISPs to facilitate the process by supporting their users who
want to run mail servers, and helping the rest of us use such techniques
to quarantine the spew from zombies and less conscientious mail admins.

I'm always willing to be educated on why it is impossible for any given
ISP to maintain an in-addr.arpa zone with PTRs for their customers who
wish to be treated like real admins, as opposed to casual consumer-grade
users with dynamically assigned addresses.

-- 
hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com
join us!   http://hesketh.com/about/careers/account_manager.htmljoin us!


Re: [eweek article] Window of anonymity when domain exists, whois not updated yet

2005-01-11 Thread Michael . Dillon

 But as article specifically mentions sending during the night and
 registration next morning that does seem to indicate eweek found out
 about no whois but with already registered domain, i.e. see

Could they simply be referring to the technique of
sending spam at night with a URL to a non-existent
domain? When everyone's NOC sees the spam for the first
time and tries to get the website shut down, it's not there.
Tickets are closed, and many people think someone else
already had the site taken down.

But, first thing in the morning, the domain is registered
just in time to accept the first queries from gullible
customers eager to find out how to collect their
lottery winnings. For a few hours, the spammers collect
phone numbers and then spend the next few days running
their telephone con.

Rinse and repeat.

When we make it too hard for legitimate businesses to
use spam as a means of advertising their product, then
only criminals will use spam. The arms race continues...

--Michael Dillon



Re: [eweek article] Window of anonymity when domain exists, whois not updated yet

2005-01-11 Thread David Barak


--- [EMAIL PROTECTED] wrote:
 When we make it too hard for legitimate businesses
 to
 use spam as a means of advertising their product,
 then
 only criminals will use spam. 

you can have my mailserver when you can pry it from my
cold, dead datacenter...

seriously, there have been various proposals ([ADV],
etc) to facilitate legit UCE, but that hasn't slowed
the arms race.  How would you recommend that we make
it easier for legit businesses?



=
David Barak
Need Geek Rock?  Try The Franchise: 
http://www.listentothefranchise.com



__ 
Do you Yahoo!? 
Yahoo! Mail - Helps protect you from nasty viruses. 
http://promotions.yahoo.com/new_mail


Re: [eweek article] Window of anonymity when domain exists, whois not updated yet

2005-01-11 Thread Nils Ketelsen

On Tue, Jan 11, 2005 at 10:14:35AM +, [EMAIL PROTECTED] wrote:

  But as article specifically mentions sending during the night and
  registration next morning that does seem to indicate eweek found out
  about no whois but with already registered domain, i.e. see
 Could they simply be referring to the technique of
 sending spam at night with a URL to a non-existent
 domain? When everyone's NOC sees the spam for the first
 time and tries to get the website shut down, it's not there.
 Tickets are closed, and many people think someone else
 already had the site taken down.

I was always interested to see how many people are
actually falling for these Spam messages. Did anybody here ever try to
register such a domain, after the mass mailing started but
before the spammer registers it? Just put a dummy page there and
then throw the access.log into a bunch of loganalyzers after a few days.



Nils


Re: [eweek article] Window of anonymity when domain exists, whois not updated yet

2005-01-11 Thread Jay Hennigan

On Tue, 11 Jan 2005, David Barak wrote:

 seriously, there have been various proposals ([ADV],
 etc) to facilitate legit UCE, but that hasn't slowed
 the arms race.  How would you recommend that we make
 it easier for legit businesses?

Legit businesses do not use spam.  The phrase Legit UCE is similar to
Legit fraud or Legit theft.

If legit businesses want to use SCE or solicited commercial email, then
such email is expected to be received and welcomed by the recipient and
by definition not spam.

--
Jay Hennigan - CCIE #7880 - Network Administration - [EMAIL PROTECTED]
WestNet:  Connecting you to the planet.  805 884-6323  WB6RDV
NetLojix Communications, Inc.  -  http://www.netlojix.com/


Re: [eweek article] Window of anonymity when domain exists, whois not updated yet

2005-01-10 Thread william(at)elan.net


On Tue, 11 Jan 2005, Suresh Ramasubramanian wrote:

 and it is being abused - well, nanog found out about this a while
 back, but the popular press (read - eweek magazine) seems to have
 discovered it now, or at least think they've discovered it .. their
 idea of the situation is a bit skewed.
 ...
 http://www.eweek.com/article2/0,1759,1749328,00.asp
One troublesome technique finding favor with spammers involves sending 
 mass mailings in the middle of the night from a domain that has not yet 
 been registered. After the mailings go out, the spammer registers the 
 domain early the next morning.

Well, spammers do sometimes register domains after mass mailing has 
already started. Its partial result of that spammer enterprises are 
no longer centralized and so one company that actually hosts websites 
that are being promoted is not necessarily same company that is doing 
mass mailing. Sometimes the order-taker spammer tells the mass-mailing 
spammer new domain to use for the spam compaign before domain is even 
registered - and while they expect to register it at the time mailing
gets started their synronization may not be precize and in any case
they actually prefer the first few people who receive such emails to not 
be able to get to the website (no whois and no dns - no chance to report 
it to hosting and quickly shut it down).

But as article specifically mentions sending during the night and
registration next morning that does seem to indicate eweek found out
about no whois but with already registered domain, i.e. see

 http://www.mail-archive.com/nanog@merit.edu/msg28312.html
 
  Read NANOG archives - Verisign now allows immediate (well, within about 10
  minutes) updates of .com/.net zones (also same for .biz) while whois data is
  still updated once or twice a day. That means if spammer registers new 
  domain
  he'll be able to use it immediatly and it'll not yet show up in whois (and 
  so
  not be immediatly identifiable to spam reporting tools) - and spammers are 
  in
  fact using this feature more and more!

-- 
William Leibzon
Elan Networks
[EMAIL PROTECTED]