RE: ISP Policies

[Michel Py]

> Tulip Rasputin wrote:
> That's why i explicitly asked for some "social/political/etc."
> reasons where an ISP may not want his traffic to traverse some
> particular AS number(s). Something which is beyond BGP to
> determine as of now ! :-)

FWIW, this is exactly how I understood the question. It's all about
"non-BGP" issues.

> I believe with the responses that i received both on the list
> and offline, that it is indeed quite normal for ISPs to filter
> routes based on the AS Paths for 'other' reasons. Reasons,
> quite beyond BGP as a protocol to handle! And this can happen,
> when an ISP doesnt want its traffic to traverse some AS(es).

I'm not sure I agree with "normal", but it is common practice indeed, a
significant part being in a  grey  area, and notice that
nobody dared to post the reasons on the ML. Trying to stay
intellectually honest, there are "good" and "bad" reasons for it. 

Using my well-known politically incorrect bluntness, I would say this
(words borrowed from several people) (disclaimer #2: this is somehow
exaggerated, but here it is anyway):
God has given men a brain and a penis, but not enough blood to operate
both of them at the same time. Although there are exceptions, when the
blood flows to the brain, men use BGP; when the blood flows to the
penis, men manipulate the AS_PATH and/or create route-maps :-D

Michel.

Re: Very peculiar Telnet probing (possibly spoofed?)

[Suresh Ramasubramanian]

Jeff Kell wrote:
I'm getting attacks from:
159.226.x.x
202.x.x.x
203.x.x.x
These /8s are shared between a whole lot of different ISPs in different 
countries.

Do the machines trying this typically look like botnets, or open proxies?
Do you notice any other traffic (malicious or otherwise) from these IPs 
immediately before or after these telnet probes?

	srs

Very peculiar Telnet probing (possibly spoofed?)

[Jeff Kell]

I have been rather reluctant to post this as I had hoped it was just a 
fluke.  But this has been going on for nearly two weeks.  We are getting 
banged by telnet probes from SE Asian sites... over 1000 different ones 
in all attacking the same address range.  I suspect but cannot prove 
that the packets are being spoofed as we are dropping (not resetting) 
the probes, yet they continue.  There are repeated probes from the same 
IP address for about 15-20 minutes or more, then it moves along, but the 
resulting router logs blocking them looks initially random (from SE Asia 
sites).  Is someone out there to make a bad statement for APNIC by 
spoofing the origins, or is this some co-ordinated attack/probe.

The high-order octed of the attackers is consistently within one of 
these /8 netblocks (though not evenly spread, and cluster around certain 
address blocks as shown).  I haven't heard of anything like this (other 
than recent SSH brute force, but this is telnet).

I'm getting attacks from:
159.226.x.x
202.x.x.x
203.x.x.x
210.x.x.x
211.x.x.x
218.x.x.x
219.x.x.x
220.x.x.x
221.x.x.x
222.x.x.x
61.x.x.x
Again, thousands of probes, about 10-20/sec when they're on a roll.  
These are attacks on a /18 subnet with only a small subnet (our secured 
servers) that is in danger (we block/drop telnet inbound to dynamic NAT 
but accept for static server translations)..

It is almost as if someone were spoofing the asian addresses to 
'simulate' an Asian attack, but what with the big bot-nets, I suppose 
that's a possibility too, but all these addresses (that I looked at) 
were SE Asian in origin.

After passing the 1000 scanner benchmarkk today, with some manual 
aggregation of obvious problem areas, it still continues.

Anyone else seeing this?  We're getting this more often than the SSHD scans.
Jeff Kell
Systems/Network Security

Re: ISP Policies

[Tulip Rasputin]

Hi Chris,
Or, you just don't want to send traffic through Bill Manning's ASN because
you dislike his hawiian T-Shirt Policy? There are probably a few hundred
reasosn why you'd avoid an ASN... In general though I'd think that like
Michel said: "It's a pain and its doing something that bgp should do for
you without lots of messing about"
That's why i explicitly asked for some "social/political/etc." reasons where 
an ISP may not want his traffic to traverse some particular AS number(s). 
Something which is beyond BGP to determine as of now ! :-)

I believe with the responses that i received both on the list and offline, 
that it is indeed quite normal for ISPs to filter routes based on the AS 
Paths for 'other' reasons. Reasons, quite beyond BGP as a protocol to 
handle! And this can happen, when an ISP doesnt want its traffic to traverse 
some AS(es).

Thanks,
Tulip

Re: ISP Policies

[Jeff Kell]

Tulip Rasputin wrote:
So can you give me an example of why and when would an ISP *not* want 
its traffic to flow via some other AS(es). Is it a normal policy to 
have, and do most of the ISPs have such policies in place? 
If you don't have a transit agreement and aren't sitting in the top tier 
peering list, you will not want traffic to flow via some other AS(es) as 
they may be blocking your advertisements inbound.  This is really a 
"tier" question.  Most end-node ASNs you will find do not want to 
provide transit traffic between their upstream ISPs (asking for trouble 
and bandwidth saturation) or at least make it a short-term emergency act 
of altruism.

You may have "dedicated" circuits or bandwidth or CIRs for certain 
services from YOUR ASN only.  They may not accept traffic that doesn't 
originate in your ASN and you're wasting time to try.  Part marketing, 
part business, part political as what transit you will support (and what 
transit your upstream(s) support).

In more practical terms, we have dedicated circuits for H.323 video, an 
IPSec link to our parent campus with the university-wide SAP/R3 traffic, 
another link restricted to ESNet (immediate peers only).  For a 
commercial ISP your mileage may vary as you are, above a certain level, 
providing transit between different administrative domains (or ASNs, or 
whatever).  You can do this with statics, with policy routing (or null 
routing), or in a local OSPF or whatever routing mechanism you have at 
your border.

Jeff

Re: ISP Policies

[william(at)elan.net]

On Thu, 9 Sep 2004, Tulip Rasputin wrote:

> Hi,
> 
> I have a general policy question.
> 
> Do the ISPs ever look for some particular AS number in the BGP AS_PATH and 
> then decide what action/preference/priority they need to take/give based on 
> the AS number(s) present in the BGP AS_PATH_SEQ/SET?

This happens all the time, but probably not quite the way you asked about it.
What does happen is that that preference for outgoing traffic is decided 
based on the AS path, I use this extensively and most of my route-maps are 
using "match as-path" for deciding which upstream link to send traffic to.

And really what else do you expect multihomed downstream isp to do if one 
upstream is known to have congestion on their link to another tier1 but
your other upsream does not have the same problem on their link to the 
same tier1?

> For instance, does it  happen that an ISP receives some BGP paths, but 
> because of some political,  social, economical, DOS attack, etc. reasons 
> decides that it doesn't want to  accept this path because some particular
> AS number is present in the BGP UPDATE.

BGP based filters also exist, but there appear to be no rules about when 
its good to set it up, so its quite rare and entire up to engineer at isp
to decide if he wants to do as-path based filter or access-list based filter.
And while I've never seen any discussion about it, I know that some people
mentioned that they have done it to some known spammer as##. But much more 
common is to use access-list and do filters based on ip blocks.

And you're correct that some people have used it during DoS attacks for 
quick filtering until they could fully discuss it with isp in question.
Usually again you'd use access-list and filter particular ip block, but if 
bad traffic appears to be coming from multiple ip blocks all from the same
isp, its quicker to just filter it entirely until situation is resolved.

> Basically, it doesn't want *its* traffic to flow via that particular AS 
> number(s). Or, if there is a mutual disagreement between two ISPs, and 
> one doesn't want  his traffic to traverse the other's AS number.
>
> Does this sort of thing ever happen? Are such restrictive policies normal in 
> the ISP/IX scenarios?

They are not "normal", but does happen. You really can't force somebody 
else to accept your traffic if they dont want to. So you should behave 
nice to your fellow isps and only send good traffic and have good
customers and then nobody would want to filter you :)

-- 
William Leibzon
Elan Networks
[EMAIL PROTECTED]

RE: ISP Policies

[Christopher L. Morrow]

On Wed, 8 Sep 2004, Michel Py wrote:

>
> > Tulip Rasputin wrote:
> > Do the ISPs ever look for some particular AS number in the BGP
> > AS_PATH and then decide what action/preference/priority they
> > need to take/give based on the AS number(s) present in the BGP
> > AS_PATH_SEQ/SET?
>
>
> If there is a question that nobody here wants to answer, this would be
> it.
>
> Short answer:
> Publicly: No, heaven forbid. I'll just let BGP do its job.
> Privately: Hell yes.

I'm not a router guy (routing atleast), but perhaps there are performance
problems inside an ASN along a path which you connect to other places? So
you might lengthen paths through/to that ASN to force traffic across
another ASN's direct connection which is less problematic?

Or, you just don't want to send traffic through Bill Manning's ASN because
you dislike his hawiian T-Shirt Policy? There are probably a few hundred
reasosn why you'd avoid an ASN... In general though I'd think that like
Michel said: "It's a pain and its doing something that bgp should do for
you without lots of messing about"

RE: ISP Policies

[Michel Py]

> Tulip Rasputin wrote:
> Do the ISPs ever look for some particular AS number in the BGP
> AS_PATH and then decide what action/preference/priority they
> need to take/give based on the AS number(s) present in the BGP
> AS_PATH_SEQ/SET?

 
If there is a question that nobody here wants to answer, this would be
it.

Short answer:
Publicly: No, heaven forbid. I'll just let BGP do its job.
Privately: Hell yes.

Michel.

Re: ISP Policies

[Tulip Rasputin]

So can you give me an example of why and when would an ISP *not* want its 
traffic to flow via some other AS(es). Is it a normal policy to have, and do 
most of the ISPs have such policies in place?

Thanks,
Tulip
- Original Message - 
From: <[EMAIL PROTECTED]>
To: "Tulip Rasputin" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, September 09, 2004 10:07 AM
Subject: Re: ISP Policies


yes.
On Thu, Sep 09, 2004 at 09:58:52AM +0530, Tulip Rasputin wrote:
Hi,
I have a general policy question.
Do the ISPs ever look for some particular AS number in the BGP AS_PATH 
and
then decide what action/preference/priority they need to take/give based 
on
the AS number(s) present in the BGP AS_PATH_SEQ/SET? For instance, does 
it
happen that an ISP receives some BGP paths, but because of some 
political,
social, economical, DOS attack, etc. reasons decides that it doesn't want
to accept this path because some particular AS number is present in the 
BGP
UPDATE.

Basically, it doesn't want *its* traffic to flow via that particular AS
number(s).
Or, if there is a mutual disagreement between two ISPs, and one doesn't
want his traffic to traverse the other's AS number.
Does this sort of thing ever happen? Are such restrictive policies normal
in the ISP/IX scenarios?
Thanks,
Tulip

Re: ISP Policies

[bmanning]

yes.


On Thu, Sep 09, 2004 at 09:58:52AM +0530, Tulip Rasputin wrote:
> 
> Hi,
> 
> I have a general policy question.
> 
> Do the ISPs ever look for some particular AS number in the BGP AS_PATH and 
> then decide what action/preference/priority they need to take/give based on 
> the AS number(s) present in the BGP AS_PATH_SEQ/SET? For instance, does it 
> happen that an ISP receives some BGP paths, but because of some political, 
> social, economical, DOS attack, etc. reasons decides that it doesn't want 
> to accept this path because some particular AS number is present in the BGP 
> UPDATE.
> 
> Basically, it doesn't want *its* traffic to flow via that particular AS 
> number(s).
> 
> Or, if there is a mutual disagreement between two ISPs, and one doesn't 
> want his traffic to traverse the other's AS number.
> 
> Does this sort of thing ever happen? Are such restrictive policies normal 
> in the ISP/IX scenarios?
> 
> Thanks,
> Tulip
> 

ISP Policies

[Tulip Rasputin]

Hi,
I have a general policy question.
Do the ISPs ever look for some particular AS number in the BGP AS_PATH and 
then decide what action/preference/priority they need to take/give based on 
the AS number(s) present in the BGP AS_PATH_SEQ/SET? For instance, does it 
happen that an ISP receives some BGP paths, but because of some political, 
social, economical, DOS attack, etc. reasons decides that it doesn't want to 
accept this path because some particular AS number is present in the BGP 
UPDATE.

Basically, it doesn't want *its* traffic to flow via that particular AS 
number(s).

Or, if there is a mutual disagreement between two ISPs, and one doesn't want 
his traffic to traverse the other's AS number.

Does this sort of thing ever happen? Are such restrictive policies normal in 
the ISP/IX scenarios?

Thanks,
Tulip

Verizon Sr. Manager in the NY/NJ Metro area

[Mike Sawicki]

Anyone know the name/contact information of a relatively high Sr.
manager at Verizon involved in their high-cap provisioning in the
NY/NJ metro region?  I have a dedicated t1 going on its 4th month on
the books without being provisioned properly.
Please reply offlist .. thanks.

Mike Sawicki
([EMAIL PROTECTED])

Re: Spammers Skirt IP Authentication Attempts

[Susan Harris]

Folks, let's stop this thread.  We've veered away from the operational
towards ... well, it's hard to define.  Anti-social?

Re: Spammers Skirt IP Authentication Attempts

[Paul Vixie]

> > I see that 56trf5.com is a real domain. Does this mean that the domain
> > name registries and DNS are now being polluted with piles of garbage
> > entries in the same way that Google searches have been polluted with
> > tons of pages full of nothing but search keywords and ads?
> > 
> 
> Yes - and there's a list of such domains that we track published as the
> ob.surbl.org zonefile (http://www.surbl.org for details)

the way i can prove that this methodology is only employed by a minority
of very-smart MTA operators is: "that it's effective."  if it were widely
used, such that it affected global spam volume and thus spammer revenue,
then the spammers would switch to different tricks.

MAPS RBL was intended to be immune to this reflexive failure mode because
it targetted address space, which was a scarcer commodity than domain names.

i recommend against deployment of anti-spam methodologies whose only
guaranteed effect is to force spammers to have to be smarter.  (they will!)
-- 
Paul Vixie

Re: Spammers Skirt IP Authentication Attempts

[Dan Mahoney, System Admin]

On Wed, 8 Sep 2004, Ricardo "Rick" Gonzalez wrote:
Ricardo,
I *do* stop spam within my domain of control.  I terminate spammers as I 
find them.  In the event a customer appears spammish in his entirety, I 
kill them.  In the event spam originates from a single ip, or a single 
customer-hosted domain name, I give the customer the chance to clean up 
the mess and get it off our network.  Bonus points are of course added if 
the customer is willing to prove their innocence by pointing the domain 
somewhere bad (like 127.0.0.1), instead of moving it off to be a landing 
site elsewhere.

There *are* of course instances where machines are compromised, or 
clueless people install old versions of formmail (which is continually 
compromised in new ways), and I get those abuse reports as well, and tend 
to them as well.

On occasion it's taken longer than necessary to kill spammers for a couple 
of interesting legal reasons I'm not at liberty to discuss in this forum, 
but I keep us clean enough that we're not on any of the major blacklists.

All this, however, is secondary to my real reason for even replying to 
your mail at all.

I'd like to applaud you personally for taking a list that I'm posting to 
with my personal email address, and dragging my job into it (there's a 
separation, there).  It shows a level of maturity I'd reserve for the 
frag-server customers we host.

This topic is still getting older, further off topic, and further and 
further away from the spirit of the list.

-Dan Mahoney

Dan:
SPF, SpamAssassin, and other measures are all steps in the right
direction in making spam less of a problem than it is today.  I
applaud you for taking part in their respective forums.
What you fail to realize is that spam is a problem best stopped within
your domain of control.  According to Google, it appears as though you
have a problem with terminating spamming customers, in accordiance
with your own AUP:
http://groups.google.com/groups?q=ezzi+spam&hl=en&lr=&ie=UTF-8&sa=N&scoring=d
What I found more alarming were this the double standards set forth by
this post:
http://groups.google.com/groups?q=&hl=en&lr=&ie=UTF-8&selm=5a29bb5.0202260613.3addb4ce%40posting.google.com&rnum=2
I'm sorry, but you aren't entitled to anything.  If you'd like to be
removed from the DNSBL's, you need to remove your offending customers.
You can't just say "these customers are spammers, block them, don't
block anyone else" and keep collecting a check from them at the end of
the month.
"A los tontos no les dura el dinero."
---Ricardo
On Wed, 8 Sep 2004 07:46:30 -0400 (EDT), Dan Mahoney, System Admin
<[EMAIL PROTECTED]> wrote:
On Wed, 8 Sep 2004, vijay gill wrote:
And randomgibberish.comcast.net will still be in all the dynamic
blacklists.
I'm subscribed to both the SpamAssassin list, and this one.
This is getting seriously off-topic.
If you like SPF, embrace it.  If not, don't.
This may very well be one of the things that time will tell on, much like
open relays, which were considered harmless, or things like telnet, which
used to be a complete standard, and now, my *remote reboot* units come SSH
capable.  Spamassassin and other spam control technologies are choosing
to.  It's ONE PIECE of a very large solution.  It's a solution to domain
forging, not to spam.  (nothing in this paragraph is anything new to this
list in the past week).
Can we please get on with our lives?
Thanks
-Dan Mahoney

On Wed, Sep 08, 2004 at 11:54:32AM +0100, Paul Jakma wrote:
Except that, SPF records are as easy to setup for a spammer, as for
you and I. If the above is a spammer, then SPF for foobar.com will
list randomgibberish.comcast.net as an authorised sender.
SPF will absolutely not have any effect on spam.
But if instead of foobar.com, it is vix.com or citibank.com, then their
SPF records will not point at randomgibberish.comcast.net as an
authorized sender. That means that if I do get a mail purporting to be
from citi from randomgibberish, I can junk it without hesitation.
/vijay
--
"It's three o'clock in the morning.  It's too late for 'oops'.  After
Locate Updates, don't even go there."
-Paul Baecker
  January 3, 2k
  Indeed, sometime after 3AM

Dan Mahoney
Techie,  Sysadmin,  WebGeek
Gushi on efnet/undernet IRC
ICQ: 13735144   AIM: LarpGM
Site:  http://www.gushi.org
---


--
"...Somebody fed you sugar.  Shit!"
--Tracy, after noticing Gatorade on my desk.
Ezzi Computers, October 18th 2003
Approx 11PM
Dan Mahoney
Techie,  Sysadmin,  WebGeek
Gushi on efnet/undernet IRC
ICQ: 13735144   AIM: LarpGM
Site:  http://www.gushi.org
---

Re: Spammers Skirt IP Authentication Attempts

[Ricardo \"Rick\" Gonzalez]

Dan:

SPF, SpamAssassin, and other measures are all steps in the right
direction in making spam less of a problem than it is today.  I
applaud you for taking part in their respective forums.

What you fail to realize is that spam is a problem best stopped within
your domain of control.  According to Google, it appears as though you
have a problem with terminating spamming customers, in accordiance
with your own AUP:

http://groups.google.com/groups?q=ezzi+spam&hl=en&lr=&ie=UTF-8&sa=N&scoring=d

What I found more alarming were this the double standards set forth by
this post:

http://groups.google.com/groups?q=&hl=en&lr=&ie=UTF-8&selm=5a29bb5.0202260613.3addb4ce%40posting.google.com&rnum=2

I'm sorry, but you aren't entitled to anything.  If you'd like to be
removed from the DNSBL's, you need to remove your offending customers.
 You can't just say "these customers are spammers, block them, don't
block anyone else" and keep collecting a check from them at the end of
the month.

"A los tontos no les dura el dinero."

---Ricardo

On Wed, 8 Sep 2004 07:46:30 -0400 (EDT), Dan Mahoney, System Admin
<[EMAIL PROTECTED]> wrote:
> 
> On Wed, 8 Sep 2004, vijay gill wrote:
> 
> And randomgibberish.comcast.net will still be in all the dynamic
> blacklists.
> 
> I'm subscribed to both the SpamAssassin list, and this one.
> 
> This is getting seriously off-topic.
> 
> If you like SPF, embrace it.  If not, don't.
> 
> This may very well be one of the things that time will tell on, much like
> open relays, which were considered harmless, or things like telnet, which
> used to be a complete standard, and now, my *remote reboot* units come SSH
> capable.  Spamassassin and other spam control technologies are choosing
> to.  It's ONE PIECE of a very large solution.  It's a solution to domain
> forging, not to spam.  (nothing in this paragraph is anything new to this
> list in the past week).
> 
> Can we please get on with our lives?
> 
> Thanks
> 
> -Dan Mahoney
> 
> 
> 
> >
> > On Wed, Sep 08, 2004 at 11:54:32AM +0100, Paul Jakma wrote:
> >>
> >> Except that, SPF records are as easy to setup for a spammer, as for
> >> you and I. If the above is a spammer, then SPF for foobar.com will
> >> list randomgibberish.comcast.net as an authorised sender.
> >>
> >> SPF will absolutely not have any effect on spam.
> >
> > But if instead of foobar.com, it is vix.com or citibank.com, then their
> > SPF records will not point at randomgibberish.comcast.net as an
> > authorized sender. That means that if I do get a mail purporting to be
> > from citi from randomgibberish, I can junk it without hesitation.
> >
> > /vijay
> >
> 
> --
> 
> "It's three o'clock in the morning.  It's too late for 'oops'.  After
> Locate Updates, don't even go there."
> 
> -Paul Baecker
>   January 3, 2k
>   Indeed, sometime after 3AM
> 
> 
> 
> Dan Mahoney
> Techie,  Sysadmin,  WebGeek
> Gushi on efnet/undernet IRC
> ICQ: 13735144   AIM: LarpGM
> Site:  http://www.gushi.org
> ---
> 
>

Re: Spammers Skirt IP Authentication Attempts

[Suresh Ramasubramanian]

[EMAIL PROTECTED] wrote:
I see that 56trf5.com is a real domain. Does this mean that
the domain name registries and DNS are now being polluted
with piles of garbage entries in the same way that Google
searches have been polluted with tons of pages full of
nothing but search keywords and ads?
Yes - and there's a list of such domains that we track published as the 
ob.surbl.org zonefile (http://www.surbl.org for details)

	srs

Re: Spammers Skirt IP Authentication Attempts

[Daniel Reed]

On 2004-09-08T15:15-0500, Robert Bonomi wrote:
) Same thing applies for 'simple' forwarding via sendmails '~/.forward'
) mechanism.  the mail server 'accepts' the mail from the original source,
) and then 're-sends' to the new destination.  That re-send originates as
) the _forwarding_party_, WITH an 'envelope from' of that forwarding party,
) even though the internal content ofthe message may show a _different_,
) and unrelated, "From" address.

My experience with Sendmail has been that the envelope sender is retained
through /etc/aliases or ~/.forward. I can confirm that qmail's .qmail
definitely retains the envelope sender of the original message.

MAIL From:<[EMAIL PROTECTED]>
RCPT To:<[EMAIL PROTECTED]>

Received: from outgoing.example.com by mail.example.net
Received-SPF: pass: outgoing.example.com allowed for example.com

MAIL From:<[EMAIL PROTECTED]>
RCPT To:<[EMAIL PROTECTED]>

Received: from mail.example.net by incoming.example.org
Received-SPF: fail: mail.example.net NOT allowed for example.com


Mailing lists get away with changing the envelope sender because the
original sender does not actually expect to receive DSNs for the message for
individual subscribers. Forwarding sites, on the other hand, can not simply
modify the envelope sender; DSNs *are* expected to track back to the
originating sender through a simple forward.

One proposal is to allow forwarding sites to modify the envelope sender in
such a way as to encode the original envelope sender in the LHS of an
@forwarding.site address. For example:

MAIL From:<[EMAIL PROTECTED]>
RCPT To:<[EMAIL PROTECTED]>

Received: from mail.example.net by incoming.example.org
Received-SPF: fail: mail.example.net allowed for example.net


A naive scheme would allow for open relaying, however. A widely-deployed
naive scheme could be used by spammers to send mail to arbitrary addresses:

for i in $list; do
mail bounce-$(echo $i | sed s/@/=/)@example.net < myspam
done

At least one anti-spam group has claimed they will list mail servers from
forwarding sites that use such an easily-exploited scheme.

:(

-- 
Daniel Reed <[EMAIL PROTECTED]> http://people.redhat.com/djr/   http://naim.n.ml.org/
1832 Savior214: that sucks that one day your just gonna die and all that
work you did learning stuff just gets a rm -rf

Re: Spammers Skirt IP Authentication Attempts

[Robert Bonomi]

> Date: Wed, 8 Sep 2004 20:15:01 +0100 (BST)
> From: Chris Edwards <[EMAIL PROTECTED]>
> Subject: Re: Spammers Skirt IP Authentication Attempts
>
> |SPF verification query gets returns one of three kinds of result:
> |  1) MISMATCH on point-of-origin vs domain 'authorized' senders.  *VERY*
> | probably spam.
>
> Either spam, or almost any item of forwarded mail :-(

Beg to differ.  Forwarded mail almost always shows an 'envelope from' of the
_forwarding_ party. 

Case in point: all email, sent to nanog is 'forwarded' to me, and the other
readers of the list.  It has an "inside address" (per the 'From:' header) of
whomever authored the message.  *BUT*, the 'envelope from', in the SMTP 
transaction is completely different:  <[EMAIL PROTECTED]>

A _successful_ SPF check on 'merit.edu' would, hopefully include  198.108.1.26
(trapdoor.merit.edu) in the list of 'official outgoing mail sources.  Ignoring
for the moment the fact that Merit hasn't added SPF records to DNS yet. :)

Same thing applies for 'simple' forwarding via sendmails '~/.forward'
mechanism.  the mail server 'accepts' the mail from the original source,
and then 're-sends' to the new destination.  That re-send originates as
the _forwarding_party_, WITH an 'envelope from' of that forwarding party,
even though the internal content ofthe message may show a _different_,
and unrelated, "From" address.

An SPF check of the _immediate_ sender does *NOT* break forwarded mail.
Unless the forwarding process is _totally_ borken, that is.  

Re: Spammers Skirt IP Authentication Attempts

[Peter Corlett]

Paul Vixie  <[EMAIL PROTECTED]> wrote:
[...]
> however, and this is the important part so everybody please pay
> attention, if you can junk something "without hesitation," then
> spammers will stop sending that kind of "something." they make their
> money on clickthroughs, final sales, and referrals, which translates
> to one thing and one thing only: "volume." if the way to keep their
> volume up means "put SPF metadata in for the domains they use" or
> even just "stop forging mail from domains that have SPF metadata"
> then that is exactly what they will do. guaranteed.

Cool, fewer double-bounces implicating me as the source of spam. I'll
take that, ta.

[...]
> i lost that bet during my MAPS years. your mileage may vary, but to
> me, SPF is just a way to rearrange the deck chairs on the Titanic.

Well, I for one would really really like to thank you for the MAPS
RBL. It may not have been a permanent solution, but it made the
difference while it still worked. If ever you have the misfortune to
find yourself in this arse end of Britain, please do claim a pint ;)

> we won't have decent interpersonal batch digital communications
> again before whitelists; everything we do in the mean time is just a
> way to prove that to the public so they'll be willing to live with
> the high cost of fully distributing trust.

As a poor bastard who seems to be BOFHing for an ISP "fixing" mail, I
can only hope that the future comes up with good ideas in the future
that will help with the tsunami. Given the 400% increase in spam that
we've seen hitting our "spam solution" in the last 3 months, anything
that can make the difference is welcome.

For the long term, I really don't know what to do. Becoming a Knuthian
email hermit is tempting given I'm getting awfully close to the 15
years myself...

-- 
PGP key ID E85DC776 - finger [EMAIL PROTECTED] for full key

AT&T Wireless IP Clue

[Steve Rubin]

Does anyone have an IP clue contact at AT&T Wireless?  They have some 
sort of filter blocking most (all?) of 69/8 to their SMS email gateway, 
and even the AT&T Wireless NOC can't seem to find the problem 
(800-832-6662, option 6, ticket #1087071).  I was leaning towards 69/8 
bogon filters until I noticed that twice a day for about 30 minutes 
everything works.

Re: who's next?

[Fred Baker]

At 04:29 PM 09/08/04 +, Paul Vixie wrote:
i guess this is progress.  the press keeps bleating about stopping spam 
from being received -- perhaps if they start paying attention to how it 
gets sent and how many supposedly-legitimate businesses profit from the 
sending, there could be some flattening of the spam growth curve.
I think both approaches have value.
Consider this by comparison to the "war against drugs". One line of 
reasoning says "if there is no supply, there will be no market". Another 
line of reasoning says "if there is no demand, there will be no market". A 
third line of reasoning notes that with purveyance of such come a multitude 
of other social ills, and focuses on the "businessmen" in the trade: "if 
there is no way for supply and demand to meet, the market will fail."

Believe it or not, there is a market for spam. One person in a zillion 
actually replies to email claiming to be from the survivors of deposed 
African officials, resulting in them being able to fleece another sucker. 
If nobody replied, sooner or later they would get tired of sending the 
stuff. And yes, if they stop sending the stuff (perhaps as a result of 
going to jail), we won't have to deal with it. And oh by the way, a way to 
help them decide to not send it is to disable them from getting access to 
the net.

So, I say, consider spam to be fraud or theft of service when it is, and 
apply anti-fraud or anti-theft laws to the spammers. Consider it to be a 
costly nuisance to the receiver, and provide a way for him to inexpensively 
and reliably sort wheat from chaff (signatures and reputation services, 
which are not about "I signed my email so I'm cool" as much as they are 
about "I really am who I say I am, and you may apply policies as you see 
fit to deal with my email"), preferably without having to actually see the 
chaff. And yes, deny the spammer access.

Where this gets interesting is with so-called "legitimate spam". At least 
under US law, if you and I have a relationship as buyer and seller, the 
seller has a right to advertise legitimate services and products to the 
buyer. I travel in a vertical direction when I get spam from my employer; I 
have sat down with the designated spammer and have been told in detail that 
as a user of that equipment I am a buyer and they have a right to advertise 
to me, and take pretty serious steps to target and not annoy their 
audience. There is a part of me that wants to site in an 18" gun using 
their building as a target; there is another part of me that notes the 
photography in magazines and on billboards and the little jingles that go 
by on TV and the radio, and notices that legitimate advertising is in fact 
treated as (ulp!) legitimate.

In that case, they're not going to jail, and no ISP is going to refuse them 
service. I just want the ability to say "but I choose to not receive email 
from the designated spammer, and need to be able to reliably identify email 
from him in order to enforce that policy." 

pgpiHNlAIksee.pgp
Description: PGP signature

Re: Spammers Skirt IP Authentication Attempts

[Robert Bonomi]

> From [EMAIL PROTECTED]  Wed Sep  8 12:05:02 2004
> To: [EMAIL PROTECTED]
> Subject: Re: Spammers Skirt IP Authentication Attempts
> From: Paul Vixie <[EMAIL PROTECTED]>
> Date: 08 Sep 2004 16:59:51 +
>
>
> [EMAIL PROTECTED] (vijay gill) writes:
>
> > ...  That means that if I do get a mail purporting to be from citi from
> > randomgibberish, I can junk it without hesitation.
>
> agreed, that is what it means.
>
> however, and this is the important part so everybody please pay attention,
> if you can junk something "without hesitation," then spammers will stop
> sending that kind of "something."  they make their money on clickthroughs,
> final sales, and referrals, which translates to one thing and one thing
> only: "volume."  if the way to keep their volume up means "put SPF metadata
> in for the domains they use" or even just "stop forging mail from domains
> that have SPF metadata" then that is exactly what they will do.  guaranteed.
>
> there's a bet here.  you could bet that by closing off this avenue, SPF will
> force spammers to use other methods that are more easily detected/filtered,
> and that if you play this cat&mouse game long enough, it will drive the cost
> of spam so high (or drive the volume benefit so low) that it'll just die out.
>

I, for one, don't think that SPF is a FUSSP (tm vernon), or anything close to
it.

I _do_ think that it is _a_step_ 'in the right direction'. I'd *love* to
see SPF-type data returned on rDNS queries -- that would practically put 
the zombie spam-sending machines out of business.

SPF _can_ serve a 'useful function' in spam-fighting. As follows:

   SPF verification query gets returns one of three kinds of result:
 1) MISMATCH on point-of-origin vs domain 'authorized' senders.  *VERY*
probably spam.  Need a white-list check of the specific sender e-mail,
and if that fails, an SMTP-session rejection is indicated.
 2) MATCH on point-of-origin for domain vs domain 'authorized' senders.
'reliable' data-point that the domain owner 'authorized' the use
of the domain-name.  Now it makes sense to query an _internally_
_maintained_ database of 'familiar to me' domains, to see what types
of prior mail from this domain have been seen.   This is a much
simpler, quicker, less CPU-intensive test than the 'full' set of
spam checks.  Match on 'known spammer' domain causes immediate 
SMTP-time rejection; match on 'known NON-ISP, non-spammer' domain 
and one is quite 'safe' in accepting the message without further
checks.  Messages from 'unfamiliar' domains, and/or 'ISP' domains,
get the full spam-check treatment.
 3) NO DATA.  In this scenario, doing the full set of spam checks, is
unavoidable.  Unless you reject traffic based on the lack of SPF
data; which is a non-starter strategy, until such time as SPF is 
near-universally deployed.

If _nobody_ published SPF data, then the situation degenerates into case 3),
as a worst-case scenario. This is no worse than the situation _without_ SPF
checking.  (For the nit-pickers, yes, it is a _little_ worse, by the overhead
of the 100% no-constructive-date SPF queries.)

If a 'non trivial' share of the incoming message traffic falls into case 1)
and/or case 2), then the use of SPF is a net 'win' for the recipient.

*IF* the time comes when SPF deployment is near-univeral, then case 3) drops
out of the picture.  _IN_THAT_CASE_, spammers pretty much _have_ to publish
SPF data for their outgoing mail sources, to have any 'hope' of delivery.
Whereupon, either they're sending from 'known spammer' domains, or the
'unfamiliar domain' handling kicks in.

It aint the (or even 'a') FUSSP,  But it is a _big_ win for places that handle
large volumes of e-mail.  For those big shops, it doesn't take long for a
spammer domain to get out of the 'unrecognied' category, and into the 'known
spammer' class.  Whereupon, one SPF check, plus one internal database dip, and
they can dump the mail as from 'known spammers'.  The savings in system
resources, by using such an approach on several _billion_ pieces of mail per
day is definitely non-trivial.

It takes a while for wide-spread acceptance/implementation, but when that
state of affairs _is_ achieved, large-scale spammers have a serious problem:
  Messages claiming to be from sources lacking SPF validation get rejected.
  Messages with SPF-mismatch get bit-bucketed.
  Messages with SPF-validation from identified spammer domains get bit-bucketed

What's an _honest_ spammer to do? 

Re: Spammers Skirt IP Authentication Attempts

[Douglas Otis]

On Wed, 2004-09-08 at 09:59, Paul Vixie wrote:
> [EMAIL PROTECTED] (vijay gill) writes:
> 
> > ...  That means that if I do get a mail purporting to be from citi from
> > randomgibberish, I can junk it without hesitation.
> 
> agreed, that is what it means.
> 
> however, and this is the important part so everybody please pay attention,
> if you can junk something "without hesitation," then spammers will stop
> sending that kind of "something."  they make their money on clickthroughs,
> final sales, and referrals, which translates to one thing and one thing
> only: "volume."  if the way to keep their volume up means "put SPF metadata
> in for the domains they use" or even just "stop forging mail from domains
> that have SPF metadata" then that is exactly what they will do.  guaranteed.
> 
> there's a bet here.  you could bet that by closing off this avenue, SPF will
> force spammers to use other methods that are more easily detected/filtered,
> and that if you play this cat&mouse game long enough, it will drive the cost
> of spam so high (or drive the volume benefit so low) that it'll just die out.
> 
> i lost that bet during my MAPS years.  your mileage may vary, but to me, SPF
> is just a way to rearrange the deck chairs on the Titanic.  we won't have
> decent interpersonal batch digital communications again before whitelists;
> everything we do in the mean time is just a way to prove that to the public
> so they'll be willing to live with the high cost of fully distributing trust.

The first step along this path is to ensure a means of obtaining a name
that can be used to establish a history of use.  Neither SPF or
Sender-ID provides a domain name without making unverifiable assumptions
of the mail channel integrity.  The CSV proposal, now in the MARID
group, provides a means of obtaining both an authenticated and
authorized name useful for establishing a history without the high
overhead associated with tracking addresses.

SPF and Sender-ID expect the recipient to expend perhaps hundreds of DNS
queries and execute complex macros that are seemingly designed to hide
the scope of the outbound SMTP addresses, where a single wildcard record
and random sub-domains will devour the recipient's resolver.  

Neither Sender-ID nor SPF stop the citibank.com spoofing, as the last
header checked is the RFC2822 From.  Spoofers only need to employ a few
simple tricks, and the phishing continues, but now with a receiving MTA
burning more than twice the network and iron.  Sender-ID seems to be a
means of injecting Microsoft IPR and to place a foot in the door to
allow never-ending feature creep and DNS bloat.

-Doug

  

Re: who's next?

[Jeroen Massar]

(oh oh spam talk on nanog ;)

On Wed, 2004-09-08 at 18:29, Paul Vixie wrote:
> in  we see:
> 
>Campaigners against spam on the internet have won a major battle
>against the world's second largest internet service provider.
> 
>US firm Savvis was allegedly earning up to $2 million a month from
>148 of the world's worst spammers, a former employee had claimed.
> 
>Following talks with anti-spam groups, Savvis has now promised to get
>rid of the spammers using its network.

Making a promise is different from actually doing it...
With $2 million/month it is quite probably that someone will want to
have that business, thus it will just shift around, probably to some
sub-company not carrying the name "Savvis" anymore, "Spammis" is
probably then the better name ;)

> i guess this is progress.  the press keeps bleating about stopping spam
> from being received -- perhaps if they start paying attention to how it
> gets sent and how many supposedly-legitimate businesses profit from the
> sending, there could be some flattening of the spam growth curve.

Exactly... just as long as some people get paid and don't get caught we
will use SpamAssasin and the various ingenious methods to avoid them ;)

Greets,
 Jeroen



signature.asc
Description: This is a digitally signed message part

Re: Spammers Skirt IP Authentication Attempts

[Stephen J. Wilcox]

On Wed, 8 Sep 2004, Paul Jakma wrote:

> Yes, all we need for SPF to work is for spammers to play along and 
> cooperate, and we'll be able to filter out the spam they send.

doesnt matter if they do, the point is this provides a type of whitelisting for
major domains that are being abused eg phishing, and scales down so you can even
flag up fakes for minor domains

just another weapon in the arsenal and what i like is that its very low overhead 
unlike some techniques, and is also managed by the domain admin 

Steve

Re: Spammers Skirt IP Authentication Attempts

[Paul Vixie]

[EMAIL PROTECTED] (vijay gill) writes:

> ...  That means that if I do get a mail purporting to be from citi from
> randomgibberish, I can junk it without hesitation.

agreed, that is what it means.

however, and this is the important part so everybody please pay attention,
if you can junk something "without hesitation," then spammers will stop
sending that kind of "something."  they make their money on clickthroughs,
final sales, and referrals, which translates to one thing and one thing
only: "volume."  if the way to keep their volume up means "put SPF metadata
in for the domains they use" or even just "stop forging mail from domains
that have SPF metadata" then that is exactly what they will do.  guaranteed.

there's a bet here.  you could bet that by closing off this avenue, SPF will
force spammers to use other methods that are more easily detected/filtered,
and that if you play this cat&mouse game long enough, it will drive the cost
of spam so high (or drive the volume benefit so low) that it'll just die out.

i lost that bet during my MAPS years.  your mileage may vary, but to me, SPF
is just a way to rearrange the deck chairs on the Titanic.  we won't have
decent interpersonal batch digital communications again before whitelists;
everything we do in the mean time is just a way to prove that to the public
so they'll be willing to live with the high cost of fully distributing trust.
-- 
Paul Vixie

who's next?

[Paul Vixie]

in  we see:

   Campaigners against spam on the internet have won a major battle
   against the world's second largest internet service provider.

   US firm Savvis was allegedly earning up to $2 million a month from
   148 of the world's worst spammers, a former employee had claimed.

   Following talks with anti-spam groups, Savvis has now promised to get
   rid of the spammers using its network.

   ...

i guess this is progress.  the press keeps bleating about stopping spam
from being received -- perhaps if they start paying attention to how it
gets sent and how many supposedly-legitimate businesses profit from the
sending, there could be some flattening of the spam growth curve.

Re: Spammers Skirt IP Authentication Attempts

[Paul Vixie]

> True, but bounces, and anything else with NULL return path, can be taken
> care of with SRS.

SRS is probably a higher pairwise deployment barrier than SPF.  but in any
case you should take this argument to the IETF MARID WG, since getting
agreement on nanog@ (assuming it's possible) won't stop the SPF steamroller.

> See:
> 
>   http://www.libsrs2.org/
>   http://www.libsrs2.org/srs/srs.pdf
>   http://asarian-host.net/srs/sendmailsrs.htm
> 
> And be happy, and realise "SPF is worthless" ;)

SRS looks like a better technical solution than SPF, but it's less deployable.
for one thing, There Can Be Only One SRS-like thing.  there are already many
SPF-like things, each with its own adherent-base, and there will be many more.

> Is it really worth it for every domain owner on the planet (including
> spammers!) to implement SPF records in DNS, and the resulting forwarding
> breakage, simply to provide some fairly intangible "dilution protection"
> for, primarily, the very small subset of widely-known domains out there?

no.  it's the same kind of cost/benefit assymetry as spam, where everybody
has to pay a higher cost but only a few get a significant benefit from it.

however, beta was better than vhs, too.  and tully's is way Way better than
starbucks.  being better isn't as relevant as having better marketing.  with
microsoft backing SPF++ (is it "sender-id" now?), SPF will be widely deployed
and the costs and benefits be damned.

> > ...  i'm glad that companies bigger and richer than i am find it in
> > their own selfish best interests to push something like SPF -- that
> > means it'll happen.  ...
> 
> Well that depends. At the moment it looks like the clients will
> implement a standard that most of the servers will not!

i've begun to hear privacy related concerns, as well.  even with jim miller's
MAIL-FROM proposal, there's a way to look at the DNS query stream and find
out what servers are presently being spammed using your domain name as the
source.  this is an information leak but i'm willing to live with it.  many
MTA operators will not be willing to live with this.  (maybe some large ones.)

> > it's useful, just not for the advertised reasons, or a universal reason.
> 
> Ah, absolutely yes.

so, i'll take your "SPF is worthless!" statement under advisement.

summary (Re: OT- need a new GSM provider )

[Paul Vixie]

i'd asked:

> >  Anybody had notable (good or bad) billing and/or customer service
> > experiences with Voicestream or any other GSM provider with native
> > coverage in the San Francisco Bay Area?

many people said:

> I think Voicestream and T-Mobile are the same company now.  If you've
> had problems with one, you'll likely have 'em again.

now, most of the problems i'm having are due to statistical anomolies
(in which BigTelCo is optimized for the average case, and i'm some kind
of an exception).  in that light, my problems are completely portable.
however, AT&T is more statistically driven (that is, they've optimized
their value proposition) than even t-mobile was.  i may end up going
back to t-mobile, since t-mobile appears to have lost the "race to the
bottom" at least for now.  you never know how good you had it until after
you switch to AT&T, or something.

i won't be switching to CDMA or any other non-GSM.  just because us-gov
deliberately allowed contractors to put closed, non-GSM systems into iraq
and afghanistan does not mean i'm ready to be locked into old (bad) ways
of doing my telco.  until we have ubiquitous 802.11 so that i can roam with
a SIP phone, GSM is the closest thing to "right".  this isn't a technology
problem -- GSM might be horrible under the covers, i don't know or care.
if another multi-vendor international standard is proposed, i'll look at it.

other observations (anonymized) that came in on this thread:

---

> Bad news, in the bay area, T-Mobile == Voicestream. 
> You could go for Cingular, but you won't be any happier.  The bad news
> is that every GSM provider here just plain sucks.

i'll stop including similar statements after this one.  i'm struck by the
fact that no matter what BigTelCo you ask about, you can hear a plethora
of horror stories.  somewhere, there may even be a happy AT&T customer or
two.  for the record, the best customer service experience i ever had was
with NexTel, but since my office building kept moving in and out of the
coverage region all day long, i had to switch to a company who could keep
up with us.  (i guess it's a san andreas fault thing.)  so, the best
provider might be the one with the best network, or the best prices, or
the best customer service -- it's subjective.

it does make me wonder if there's some kind of antitrust issue involved
in the whole "race to the bottom" thing.  the carriers are competing to see
who can best-optimize their channels (spend the least, make the most) and
the only reason they don't go out of business as a result is that every
other provider is doing the same thing.  if any provider were to "break
ranks" and decide not to squeeze the margins quite so hard, they could make
up by 1X in volume what they "lost" by not constantly searching for
their customers' collective pain threshold.  but i'm bitter, and i digress.

---

> I support about 15 cell users on a half dozen various providers, and
> in dealings with support departments i've found T-Mobile to be the
> least-horrible. No idea on your particular billing issues though, all
> the folks there I have spoken with have had at least slight clue.
> 
> I concur on avoiding AT&T like a plague.

t-mobile's inability to let my phone ring through was the big issue.  my
call queuing system relies on timeouts to go to the next endstation.  but
t-mobile insisted on terminating every call that came to them, whether i
was in coverage or not, whether i answered the call or not.  i could choose
between a voicemail answerbot or an error message, but they were unwilling
to just let it ring.  i got the idea that this was so they could collect
call termination fees no matter what -- another "race to the bottom" idea.
but it meant that my follow-me technology had to terminate in my t-mobile
number, and t-mobile had to be configured to forward unanswered calls to
my second, secret, hidden phone number, that continued my ring-queue and
put my voicemail into my centralized inbox.  and of course t-mobile charged
me by the minute for the forwarded calls, even though they were local, and
even though i was on the highest-priced possible calling plan.  again, i'm
a statistical anomoly for these people.  they make their money from volume,
and if i can't fit into their profile, they can't afford to try to please me.

---

> Paul, you're pretty much left with cingular if you can't deal with
> tmobile/voicestream and ATT.  ATT will be merged in with cingular in a
> few months.  Other option is to get a Verizon samsung worldphone, which
> will roam onto vodafone GSM internationally and us CDMA.  That is sim
> locked though.

yeah, well, i'm done with sim-locked anything.

> Also, do NOT get a triband phone, most triband phones are 900/1800/1900.
> The largest amount of US GSM (both cingular and ATT) are implemented on
> GSM 850. So you either want a quad band like the v600 or treo 600 which
> can operate on the US (850/1900) gsm bands as well as the international
> 900/1800 bands.

tha

RE: MPLS signaling

[Rump Bryant]

I think this depends on the network.  Most major tier 1 public IP backbones
do not necessarily run QoS through the core.  MPLS in these networks is used
for traffic engineering such as constraint-based routing and dynamic LSPs.
Private MPLS-based networks may (and do) use dynamic QoS signaling. Maybe
someone who maintains one of these networks could chime in.

Bryant

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul
Khavkine
Sent: Tuesday, September 07, 2004 4:27 PM
To: Rump Bryant
Cc: [EMAIL PROTECTED]
Subject: RE: MPLS signaling



So most people do manual QoS/bandwidth provisioning ?

I'm looking into this for L2 over MPLS VPN (Martini draft).


Thanx
Paul

On Tue, 7 Sep 2004, Rump Bryant wrote:

>
>RSVP is commonly used for LSP signaling/setup at least in one of the 
>largest tier one's MPLS architecture.  I'm not sure how many large ISPs 
>use e2e QoS enforcement (none in my experience with public IP 
>networks).  Several use DSCP (actually IP Precedence) at the edge (CPE 
>to ISP edge only).  RSVP-TE could be used if there was a need 
>(reserving bandwidth) for e2e QoS signaling, or alternatively perhaps 
>Bandwidth Broker
>(http://qbone.internet2.edu/bb/index.shtml) might be employed for the 
>same purpose.
>
>
>Bryant Rump
>Advanced Internetworking
>Booz Allen Hamilton
>[EMAIL PROTECTED]
>
>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of 
>Paul Khavkine
>Sent: Tuesday, September 07, 2004 12:36 PM
>To: [EMAIL PROTECTED]
>Subject: MPLS signaling
>
>
>
>
>Hi folks.
>
>
>What is the most common way of doing MPLS signaling for LSP setup and 
>End to End QoS enforcement ?
>
>LDP ? RSVP ? BGP-TE  or OSPF-TE ?
>
>Thanx
>Paul
>
>
>Paul Khavkine
>Network Administrator
>DISTRIBUTEL Communications.
>740 Notre Dame West, Suite 1135
>Montreal, Quebec, Canada, H3C 3X6
>1-514-877-5505 x 263
>http://www.distributel.net
>
>
>



Paul Khavkine
Network Administrator
DISTRIBUTEL Communications.
740 Notre Dame West, Suite 1135
Montreal, Quebec, Canada, H3C 3X6
1-514-877-5505 x 263
http://www.distributel.net

Re: Spammers Skirt IP Authentication Attempts

[Richard Cox]

On Wed, 8 Sep 2004 13:52:59 +0100 <[EMAIL PROTECTED]> asked:

> I see that 56trf5.com is a real domain. Does this mean that the domain
> name registries and DNS are now being polluted with piles of garbage
> entries in the same way that Google searches have been polluted with
> tons of pages full of nothing but search keywords and ads?

Yes.  Hadn't you noticed?

Statistically speaking there are now more domains with fake contact
records than there are with genuine contact records, and certain
registrars have been allowing new domains to be registered using
contact addresses that have previously been proved to be bogus.

-- 
Richard Cox

Re: Spammers Skirt IP Authentication Attempts

[Paul Jakma]

On Wed, 8 Sep 2004, David Cantrell wrote:
Sure.  But then, SPF is not meant to prevent all spam.
s/all//
It would (if widely deployed) have a very wide effect on spam with 
forged senders though, and the consequent bounces to innocent third 
parties.
I agree bounce reduction would be a good thing. But, I'm sure I've 
mentioned it already, *SRS achieves same thing* without breakage.

To put it as an analogy (seems the done thing), I can use a plank of 
wood (SPF) to bang nails into a wall, but given the existence of 
hammer (SRS), the plank doesnt cut it ;)

(and handing out planks so other people can make shelves isnt 
interesting).

The hype does not come from the people working on SPF, but from 
clueless hangers-on who apparently can't read.
Possible ;)
Anyway, enough. The topic is indeed OT, and i'm just a net.kook.
regards,
--
Paul Jakma  [EMAIL PROTECTED]   [EMAIL PROTECTED]   Key ID: 64A2FF6A
Fortune:
Publishing a volume of verse is like dropping a rose petal down the
Grand Canyon and waiting for the echo.

Re: Spammers Skirt IP Authentication Attempts

[Michael . Dillon]

> For the second one: no.  Because knowing that sender is unforged/real
> doesn't, in and of itself, do you any good *with respect to stopping 
spam*.
> You ALSO need a way to know that 56trf5.com is a spam source domain.

I see that 56trf5.com is a real domain. Does this mean that
the domain name registries and DNS are now being polluted
with piles of garbage entries in the same way that Google
searches have been polluted with tons of pages full of
nothing but search keywords and ads?

--Michael Dillon

Re: Spammers Skirt IP Authentication Attempts

[Rich Kulawiec]

On Mon, Sep 06, 2004 at 07:19:01PM -0400, Mark Jeftovic wrote:
> I'm not sure the people behind this concept (SPF, RMX, et al) ever
> intended it to be the FUSSP, but a lot of the ensuing enthusiasm
> built it up to that.

Consider that the people behind SPF made this statement (upon
introducing it):

"Spam as a technical problem is solved by SPF."

If, therefore, there is an overabundance of enthusiasm for that concept,
then it seems to be very clear where full responsibility for that rests.

> I've *never* viewed SPF as an "antispam" methodology, but considered
> it an inevitable utility of the DNS system. Other methods are
> evolving to deal with spam, don't confuse them with what SPF is,
> which is essentially an authentication/identification framework
> that has the ability to mitigate one of the more popularly used
> spam obfuscation techniques.

I'll agree with you that it may mitigate one of the more popularly
used spammer obfuscation techniques, but that particular technique is
a minor problem (considering spam/abuse as a whole) and not all that
worth solving -- since *other* spammer obfuscation techniques which
SPF (and DomainKeys and SenderID et.al.) don't address are already
available and being used.  (Why aren't they used more?  Spammers haven't
needed to.  But if pressed, they will.  Rapidly.)

The bigger problem isn't the spammer obfuscation technique: it's the
backscatter from all the mail systems which bounce instead of reject,
Bouncing was not all *that* unreasonable until we started to operate in an
environment with massive SMTP forgery (from spam/viruses/etc.) -- several
years ago.  It's now much more desirable to reject whenever possible,
saving everyone bandwidth/cycles/grief.  I don't think I like the idea
of wallpapering over this problem with SPf/DomainKeys/etc.: I think I'd
rather see those mail systems fixed to deal with the environment they
find themselves in.

[ Especially because the other spammer obfuscation techniques
I referred to are available, and will be used if and when SPF
or DomainKeys or any of these are widely deployed.  Thus, mail
systems will *still* inhabit an environment of massive forgery
and should be prepared to deal with it as best they can...where
I think one approach to that is "don't make it any worse". ]

Yeah, that may be a lot of work to complete -- although there are a
myriad of simple techniques available to at least mitigate it, if not
eliminate it entirely, and any relief would be welcome.

> That spammers are publishing SPF records is in no way indicative
> of an inherent flaw in SPF's objectives or a failure in its
> implementation, in fact, I welcome spammers who publish SPF
> data detailing the originating points of their email. If
> more "known spam domains" did this, a handy DNSBL could be
> constructed out of such data (with a few caveats of course,
> it would also potentially open the door to a type of DoS attack).

RHSBLs (i.e. DNSBLs which list domain names instead of IP addresses, thus
"Right-Hand-Side BL's") have already been built.  See www.surbl.org and
www.ahbl.org, for example.

But this tactic doesn't work -- as an anti-spam technique -- as well
as we might hope, for three reasons:

1. Spammers have an [effectively] infinite supply of domains.

This won't change because spammers who burn through domains rapidly
(and thus need to purchase more) are some of the registrars' best customers.
They're also early adopters of "obfuscated registration", so much so that
it's becoming increasingly likely that any domain thus registered is
declaring "intent to abuse". [1]

2. Spammers control a large -- as in tens of millions -- number
of zombies. [2]

This won't change because none of the three entities who could do anything
about it (the zombies' former owners, consumer broadband ISPs, Microsoft)
are willing to step up, admit there's a problem, and do whatever it takes
to fix it.

3. Mail from a forged sender is operationally indistinguishable
from mail from an unforged but unknown sender. [3]

This won't change either.  And because of #1, spammers have an essentially
infinite number of domains to do it with, and because of #2, they have a
large number of systems to do it from.

And as a result, a *lot* of things that we could try, not just
SPF/DomainKeys/et.al., just won't work.  (Example?  Oh, take the various
"hashcash" ideas that have been floated: getting into a computing cycle
contest with spammers is a guaranteed loss.)

---Rsk

[1] For example, one group of pirate-software spammers appears to be
burning through domains at the rate of one every 24-48 hours, and has
been doing this for months.

[2]  It's hard to know how many systems are zombies, but "tens of millions"
is probably the right order of magnitude.  I did a back-of-the-envelope
calculation a few months and came up with 10 to 20 million; Carl Hutzler
(of AOL Policy Enforcement) pr

Re: Spammers Skirt IP Authentication Attempts

[vijay gill]

On Wed, Sep 08, 2004 at 12:14:54PM +0100, Paul Jakma wrote:
> On Wed, 8 Sep 2004, vijay gill wrote:
> 
> >But if instead of foobar.com, it is vix.com or citibank.com, then 
> >their SPF records will not point at randomgibberish.comcast.net as 
> >an authorized sender. That means that if I do get a mail purporting 
> >to be from citi from randomgibberish, I can junk it without 
> >hesitation.
> 
> Yes, all we need for SPF to work is for spammers to play along and 
> cooperate, and we'll be able to filter out the spam they send.
> 
> Earth calling... ;)

I'm probably going into an argument with a net.kook but just to be sure,
let me clarify this: How do you think spammers will be able to subvert
citibank.com to have random.cablemodem.net as a permitted sender?

I've never believed spf was the ultimate solution, just that it allows me to
better filter some of the joe-bobs.

/vijay - falling yet again into another argument which is probably more
annoying than a thorned thong.

Re: Spammers Skirt IP Authentication Attempts

[Dan Mahoney, System Admin]

On Wed, 8 Sep 2004, vijay gill wrote:
And randomgibberish.comcast.net will still be in all the dynamic 
blacklists.

I'm subscribed to both the SpamAssassin list, and this one.
This is getting seriously off-topic.
If you like SPF, embrace it.  If not, don't.
This may very well be one of the things that time will tell on, much like 
open relays, which were considered harmless, or things like telnet, which 
used to be a complete standard, and now, my *remote reboot* units come SSH 
capable.  Spamassassin and other spam control technologies are choosing 
to.  It's ONE PIECE of a very large solution.  It's a solution to domain 
forging, not to spam.  (nothing in this paragraph is anything new to this 
list in the past week).

Can we please get on with our lives?
Thanks
-Dan Mahoney
On Wed, Sep 08, 2004 at 11:54:32AM +0100, Paul Jakma wrote:
Except that, SPF records are as easy to setup for a spammer, as for
you and I. If the above is a spammer, then SPF for foobar.com will
list randomgibberish.comcast.net as an authorised sender.
SPF will absolutely not have any effect on spam.
But if instead of foobar.com, it is vix.com or citibank.com, then their
SPF records will not point at randomgibberish.comcast.net as an
authorized sender. That means that if I do get a mail purporting to be
from citi from randomgibberish, I can junk it without hesitation.
/vijay
--
"It's three o'clock in the morning.  It's too late for 'oops'.  After
Locate Updates, don't even go there."
-Paul Baecker
 January 3, 2k
 Indeed, sometime after 3AM
Dan Mahoney
Techie,  Sysadmin,  WebGeek
Gushi on efnet/undernet IRC
ICQ: 13735144   AIM: LarpGM
Site:  http://www.gushi.org
---

Re: Spammers Skirt IP Authentication Attempts

[Paul Jakma]

On Wed, 8 Sep 2004, Florian Weimer wrote:
If there's significant deployment on the MTA side, it might 
mitigate the impact of delayed bounces for those who post 
authoritative SPF records.
No offence, but did you read my reply to Paul Vixie?
Delayed bounces, any any other NULL return path bot-mail, can be 
taken care of with SRS.

care about responsible Internet Mail handling.  Therefore, it's 
unlikely that we'll see significant deployment of a technology that 
is as controversial as SPF.
Good thing too.
regards,
--
Paul Jakma  [EMAIL PROTECTED]   [EMAIL PROTECTED]   Key ID: 64A2FF6A
Fortune:
You will be surprised by a loud noise.

Re: Spammers Skirt IP Authentication Attempts

[Paul Jakma]

On Wed, 8 Sep 2004, vijay gill wrote:
But if instead of foobar.com, it is vix.com or citibank.com, then 
their SPF records will not point at randomgibberish.comcast.net as 
an authorized sender. That means that if I do get a mail purporting 
to be from citi from randomgibberish, I can junk it without 
hesitation.
Yes, all we need for SPF to work is for spammers to play along and 
cooperate, and we'll be able to filter out the spam they send.

Earth calling... ;)
/vijay
regards,
--
Paul Jakma  [EMAIL PROTECTED]   [EMAIL PROTECTED]   Key ID: 64A2FF6A
Fortune:
The Constitution may not be perfect, but it's a lot better than what we've got!

Re: Spammers Skirt IP Authentication Attempts

[vijay gill]

On Wed, Sep 08, 2004 at 11:54:32AM +0100, Paul Jakma wrote:
> 
> Except that, SPF records are as easy to setup for a spammer, as for 
> you and I. If the above is a spammer, then SPF for foobar.com will 
> list randomgibberish.comcast.net as an authorised sender.
> 
> SPF will absolutely not have any effect on spam.

But if instead of foobar.com, it is vix.com or citibank.com, then their
SPF records will not point at randomgibberish.comcast.net as an
authorized sender. That means that if I do get a mail purporting to be
from citi from randomgibberish, I can junk it without hesitation.

/vijay

Re: Spammers Skirt IP Authentication Attempts

[Paul Jakma]

On Wed, 8 Sep 2004, David Cantrell wrote:
You forget, SPF doesn't just tell you who is authorised to speak on 
behalf of foobar.com, it also tells you who is *not* authorised.
That is sort of implied, yes.
If you get mail coming in from - eg - randomgibberish.comcast.net 
claiming to be from foobar.com, then you know that it's dodgy 
unless foobar.com's SPF record says that that cable modem address 
is authorised.
Except that, SPF records are as easy to setup for a spammer, as for 
you and I. If the above is a spammer, then SPF for foobar.com will 
list randomgibberish.comcast.net as an authorised sender.

SPF will absolutely not have any effect on spam.
And I say this merely as a disciple of Vixie - he thought of a form 
of SPF /years/ ago, and he knew /years/ ago it wouldnt do anything 
for Spam. The only difference between Vixie's MAIL-FROM MX records 
and SPF is the snake-oil: Vixie was honest in his claims for what it 
could do, the hype around SPF is not.

regards,
--
Paul Jakma  [EMAIL PROTECTED]   [EMAIL PROTECTED]   Key ID: 64A2FF6A
Fortune:
Reformatting Page. Wait...

Re:

[Måns Nilsson]

--On fredag 3 september 2004 10.50 -0700 ken lindahl
<[EMAIL PROTECTED]> wrote:

>> I wouldn't suspect its on a production network at all. :)
> 
> we might disagree wrt the definition of "production" :)
> 
> http://ultralight.caltech.edu/lsr_06252004/
> 
> shows the path between caltech and cern transiting


And likewise so for the single-stream record holder, Sunet. 

The only non-average-production links on the path are the connections
between Sunet and Sprint (a separate peering for this, between two
otherwise production routers) and the end tails; not all PC machines on
Luleå University have 10GE connections to interfaces in the core of Sunet. 


-- 
Måns Nilsson Systems Specialist
+46 70 681 7204 KTHNOC
MN1334-RIPE


pgpQxCJWD1RPx.pgp
Description: PGP signature