Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

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

  • From: william(at)elan.net
  • Date: Wed Jan 12 19:50:14 2005


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

This essentially require registrars to be able to immediatly tell if
domain has valid address or not, what is valid in one country may not be
valid in another. And phone## may be temporarily deactivated sometimes
even at the request of the phone user. There are some ways to find certain
cases of invalid whois automaticly and if registrars had any interest in 
spending any resources on this, they could have it done automaticly so 
that "-" is not a valid address in the first place, but majority of cases 
do require long process of verification and spammers only new domain 
active for couple days, so in practice this is not a solution.
 
> 5) whois data MUST be normalized and available in machine-readable form
>    (such as a standard XML schema)

The protocol to provide whois data in standard XML format has been published
couple days ago as IETF standard (proposed standard?). See 
 http://www.ietf.org/rfc/rfc3981.txt
 http://www.ietf.org/rfc/rfc3982.txt
 http://www.ietf.org/rfc/rfc3983.txt

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

This is something for ICANN and I do believe that we should be compiling
data on the registrars that do not provide whois in real-time when they
should (per ICANN agreement) and have ways to report it to them so that
some action could be taken by ICANN (an official warning with multiple
ones leading to suspension of accreditation would do the trick with bad 
registrars). 

[compile data and provide it in public and to icann on non-answering 
whois servers added to my already very long to-do list]
 
> 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.)

This is something that you can consider as being in process of migration.
As usually its a slow process to have mail servers and mail clients updated.

> 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".)

If ISPs hire (and retrain) all unemployed textile workers it will triple
connection cost for legitimate users... That is not to say that I believe
ISPs should not act on the spam reports or that its being done well right
now - there are too many large ISPs that trim costs so much that their
abuse departments are almost non-existant and there are of course those
few ISPs who deliberately not act and provide connection to spammers
(i.e. remember recently disclosed documents from SAVVIS that forced
 them to terminate more then 100 large spammers).
 
> 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.)

No. The solution for this is to stop the forgery so that you do not receive
the bounces for email you did not send in the first place. This is being
worked on and there are several solutions and I commented on this quite
recently, see http://www.mail-archive.com/nanog@merit.edu/msg28472.html
 
> 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.)

Yes, its a problem. BTW do you care if I include GMAIL in the list of 
those "large ISPs" that are not doing it right?
 
> 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.)

How do you propose to fix this? Its perfectly valid HTML because link
are specifically designed so that you can name them whatever you like
for ease of user view. So lets say we begin to disallow URL name to
be different URL, would it fix it? Not really, they will do minor
conversion and provide name that looks like URL when its not or have
the name constructed by javascript, etc. etc. Spammers do know how
to get around all these simple fixes...

> 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... ;) 

Your wish is not going to happen. You may not be reading email in html
and I may not be doing it, but when I come to my brother's house or my
parents they all do.

---
William Leibzon, Elan Networks:
 mailto: william@elan.net
Anti-Spam and Email Security Research Worksite:
 http://www.elan.net/~william/emailsecurity/





Discussion Communities


About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home


Merit Network, Inc.