Search:  

 
 
   All ForumsHot TopicsGallery






how-to block ads


 
Forums » SPF 30?
Search Topic:
view: topics flat text 
Post a:

Comments on news posted 2004-01-22 18:39:19: On the heels of Yahoo's announcement they'd be tinkering with Domain Keys to help ease their spam headache, AOL last week began implementing SPF or "Sender Permitted From", an authentication standard centered around easily identifying spammers and pr.. ..

page: 1 · 2
AuthorAll Replies

doppler

join:2003-03-31
Blue Point, NY
AOL doing something for EMAIL spam

May they continue the fight.

...

And not be the next subject of A DOS attack
from the spammers.

ddavtian

join:2000-08-19
San Jose, CA


1 edit
Very nice move, it's about time to clean up the world that's so full of SPAM. On a daily basis our company gets around 400 email messages, that's not much but still it kills our servers, bandwidth and the IT folks who need to prevent this junk from coming in everyday. Good going AOL, I just hope you guys do this right and not block legitimate emails from getting to the right inboxes.

Dave
--
www.e5interactive.com : CA Based Web Hosting Company!


Morac

join:2001-08-30
Riverside, NJ
·Comcast


1 edit
Mailing Lists

Seems like this would block all mailing lists that preserve the senders from field.

This could explain why many AOL users on mailing lists I belong to are complaining that they aren't receiving any mail.

Not to mention AOL will now block mail from ISP's that don't implement this (like Comcast).


graysonf
Premium,MVM
join:1999-07-16
Fort Lauderdale, FL

said by Morac See Profile:
Seems like this would block all mailing lists that preserve the senders from field.
The From: field is the wrong one to check, since it is not even required by the SMTP protocol, and easily forged anyway.

The envelope sender is the one to check.


ChrisDAT
Google Keyword Compsysnyc

join:2002-02-26
Hollis, NY

 We'll see...

I am skeptical if this scheme will do anything to stop all of the spam that is generated by virus infected and hijacked machines that will have the proper "credentials" to negotiate communications with a "domain-keyed" mail server.

I think the idea is a good one nonetheless, at least it will make it more difficult for "anyone" to pose as "anyone" for the purpose of sending junk mail, or viruses, or worms... It will certainly seperate the men from the boys with respect to spam, and kick up mail validation [certification?] a notch or two.


cyberthugin

join:2002-03-12
Kew Gardens, NY

 What

I kinda find this hard to beleive that Aol would do this, forget you not that these people are the ones that send me, not 1 but 2,3,4 cd's in the mail. Anyways if crackers are able to crack software they be able to crack email.
--
www.alltechneeds.com
"Your Everyday Hosting Needs"


graysonf
Premium,MVM
join:1999-07-16
Fort Lauderdale, FL

reply to ChrisDAT
Re: We'll see...

In order to have valid credentials that are going to be checked, you have to:

Have a registered domain,
Be in control of that domain,
Have a DNS server that is authoritative for the domain,
Have a mail server with the correct MX record and credentials in DNS, and
Be in control of that DNS server in order to place the credentials into it.

I don't see how a virus compromised machine is going to be able to come up with all of that.

jester121
Premium
join:2003-08-09
Lake Zurich, IL
reply to graysonf
Re: Mailing Lists

No reason to think AOL or Yahoo would suddenly start paying attention to RFCs, is there?

Then again, the nice thing about standards is there are so many to choose from...


ChrisDAT
Google Keyword Compsysnyc

join:2002-02-26
Hollis, NY

reply to graysonf
Re: We'll see...

Virus compromised and Hijacked machines can run an application that will have access to the PCs registry and applications in the same way the PC owner's mail application does, many of the hijacks actually use the same mail application using the user's configured authentication data to send mail to the same SMTP server [their ISP] that the user would use in sending an e-mail to mom.

Execute Arbitrary Code -- means the bad app. can do anything at all that the unfortunate user can do on their PC while posing as them. What should get your attention is that in addition, the bad app. also has access to all of the information on the PC's hard disk[s] AND all of the attached network [LAN and Internet] resources that the PC has access to.

It's no joke. The worst part is that these critters can infect and thus compromise your PC via your internet connection as a worm -- no e-mail involved here.

JimF

join:2003-06-15
Allentown, PA

 reply to graysonf
Don't they mean a virus (i.e., backdoor) compromised client machine, not a virus compromised SMTP server? The spam would then be like any legitimate email from that client machine insofar as SPF was concerned, but at least it would be traceable to that client.


graysonf
Premium,MVM
join:1999-07-16
Fort Lauderdale, FL

reply to ChrisDAT
Well, I think if you look at the vast majority of the recent virii out there today, they don't work the way you say.

They have their own bundled in SMTP engines, and send mail directly to the victim's mail server. The reason they do that is to avoid having ISPs notice huge loads of outgoing mail pouring off their SMTP servers. The ISP won't know anything about the problem until complaints about the direct SMTP abuse arrive.

This is also why many ISPs now block all outgoing connections to port 25 except to their own SMTP servers. Doing that prevents direct SMTP abuse altogether.

But, as you suggest, there is nothing to prevent a virus from looking into a mail client application to determine how it is configured to send mail (out thru the ISP's SMTP server) and just use it, unless SMTP auth is used with a hashed password. But that will be more noticeable by the ISP and doesn't rely on complaints coming back to be detected and halted.


ChrisDAT
Google Keyword Compsysnyc

join:2002-02-26
Hollis, NY

reply to cyberthugin
Re: What

said by cyberthugin See Profile:
...forget you not that these people are the ones that send me, not 1 but 2,3,4 cd's in the mail.
Ohhhhh boy, that certainly put a smile on my face today

Junk Mail is not illegal [yet]. Strange that we would like junk e-mail to be. Nothing in the world forces anyone to put a valid return address [let alone positive ID like fingerprints] on USPS mail -- why do we want to hold e-mail to such a high standard for mail WE DON'T WANT?

I'm still smilin, cyber-tee


Theo25

@attbi.com
Great To See This

Its great to see them stepping up to do something about this.


Vvian Kalyss

join:2003-10-14
Stage 5.0
clubs:

 reply to ChrisDAT
Re: What

Junk snail-mail postage and handling is borne by the sender -- email costs are borne by the receiver. IMO both would be treated as equally useless except for the crucial fact that email costs me and not them (time, network overhead, mailbox limits, etc). On the other hand, it takes not a little effort on their part to produce those junk packages and then mail them to me, and all I have to do is walk from my mailbox to the trash.
--
" Lust will not keep, something must be done about it "


nixen
Rockin' the Boxen
Premium
join:2002-10-04
Alexandria, VA
·Cox HSI
·Speakeasy

reply to cyberthugin
said by cyberthugin See Profile:
I kinda find this hard to beleive that Aol would do this, forget you not that these people are the ones that send me, not 1 but 2,3,4 cd's in the mail. Anyways if crackers are able to crack software they be able to crack email.

If I am reading the SPF site correctly, all that SPF really does for AOL is prevents people from sending email, claiming to be FROM AOL, unless they happen to be one of the named reverse MX hosts (and, allowing them to block traffic claiming to come from SPF-enabled zones but not in the published SPF records). Looking at the published SPF records for AOL.Com, anyone claiming to be from AOL.Com would have to connect from
152.163.225.0/24
205.188.139.0/24
205.188.144.0/24
205.188.156.0/24
205.188.157.0/24
205.188.159.0/24
64.12.136.0/24
64.12.137.0/24
64.12.138.0/24
or have a reverse name resolution of *.mx.aol.com.

Still, that's a ALOT of potential addresses. The SPF documents did not appear to be 100% clear as to whether you had to enumerate each SMTP client, or simply the valid SMTP gateways for a domain level object (and, if it's the latter, AOL may be being overly permissive in their SPF lists).

Still reading, though...

-tom
--
"There are 10 types of people in the world... those who understand binary and those who don't."
"That's only 2 types of people, moron"


DrTCP
Yours truly
Premium,ExMod 1999-04
join:1999-11-09
Round Rock, TX

This would prevent a lot of legitimate email getting to the destinations. For example, mailing lists that preserve the From address will have getting through to the users.

Also, those people using another email address instead of the ISP supplied one might have trouble as their IP will not match the IPs associated with the domain. Outsourced email services is not uncommon. I have my own registered domain and I receive my mail at the hosting site instead of my ISP. But, I have to use my own ISP to send the mail out. This is the standard practice for most people like me.

It will also prevent sending email on the road for some people.

I think they have not done the job right.

It is not unusual for AOL users to lose their email by arbitrary processes instituted by AOL. I see this yet another one of those.

More than preventing spam this is going to make email totally dysfunctional...

JPCass

join:2001-01-23
Denver, CO

Every little bit helps

This is the other shoe dropping after the CAN-SPAM act - the effectiveiness of which, by the way, I think has yet to be be proven until we see some cases prosecuted. Technical measures to authenticate e-mail - and reject illegitimate e-mail - are the logical next step to start closing the loop, and perhaps the only real solution anyway.

It seems to me that technical moves like this can also compliment legislation and enforcement. If it blocks most of the spam sent by standard means, and the rest of it is sent by the sort of really illegitimate means outlined in earlier posts - hijacked machines, etc. - then it helps to force more definition of the currently blurred line between legitimate marketing and the real bottom feeding spammers. I don't think there will be much mercy for spam sent by hijacking machines and, perhaps most importantly, the merchants being advertised by means like that. Enforcers of the law, and perhaps also ISPs, can then focus mercilessly on what remains, and perhaps even find measures to really take the money out of spam like suspending the credit card merchant accounts associated with the websites spam is advertising, or blocking the URLs that spam links to.


nixen
Rockin' the Boxen
Premium
join:2002-10-04
Alexandria, VA
·Cox HSI
·Speakeasy

reply to DrTCP
Re: What

This is server level, not user level. That is to say, a SPAMMER connects to a destination SMTP host, but claims to be from AOL.Com (either through the HELO/EHLO exchange or the FRO M exchange prior to the DATA statement). To specifically show a mailing list in action, I' ll illustrate with a header:
From mailman-bounces@mailman.ferricdomain Fri Jan 23 02:12:15 2004
Received: from mailman.ferricdomain (mkultra [XX.YY.ZZ.114])
by cataclysm.ferricdomain (8.12.10/8.12.10) with ESMTP id i0N7CEtr016691
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
for <ferric@ferricdomain>; Fri, 23 Jan 2004 02:12:15 -0500 (EST)
Received: from mkultra.ferricdomain (localhost [127.0.0.1])
by mailman.ferricdomain (Postfix) with ESMTP id BE8693A097
for <ferric@ferricdomain>; Fri, 23 Jan 2004 02:12:13 -0500 (EST)
X-Original-To: mailman@mailman.ferricdomain
Delivered-To: mailman@mailman.ferricdomain
Received: from cataclysm.ferricdomain (cataclysm.ferricdomain [XX.YY.ZZ.220])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by mailman.ferricdomain (Postfix) with ESMTP id 14B6C3A097
for <mailman@mailman.ferricdomain>; Fri, 23 Jan 2004 02:12:11 -050
0 (EST)
Received: from ferricdomain (trilluser@undertow.ferricdomain [XX.YY.ZZ.100])
(authenticated bits=0)
by cataclysm.ferricdomain (8.12.10/8.12.10) with ESMTP id i0N7C9tr016683
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
for <mailman@mailman.ferricdomain>; Fri, 23 Jan 2004 02:12:09 -050
0 (EST)
Message-ID: <4010C948.9080207@ferricdomain>
Date: Fri, 23 Jan 2004 02:12:08 -0500
From: Tom <ferric@ferricdomain>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.6b) Gecko/20031205 Thunderbird/0.4
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: mailman@mailman.ferricdomain
X-Scanned-By: MIMEDefang 2.39
Subject: [Mailman Site List] TEST
X-BeenThere: mailman@mailman.ferricdomain
X-Mailman-Version: 2.1.2
Precedence: list
List-Id: Mailman site list <mailman.mailman.ferricdomain>
List-Unsubscribe: <»mailman.ferricdomain/mailman/lis···lman>,
<mailto:mailman-request@mailman.ferricdomain?subject=unsubscribe>
List-Archive: <»mailman.ferricdomain/mailman/pri···lman>
List-Post: <mailto:mailman@mailman.ferricdomain>
List-Help: <mailto:mailman-request@mailman.ferricdomain?subject=help>
List-Subscribe: <»mailman.ferricdomain/mailman/lis···lman>,
<mailto:mailman-request@mailman.ferricdomain?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============74987973720705114=="
Sender: mailman-bounces@mailman.ferricdomain
Errors-To: mailman-bounces@mailman.ferricdomain
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on
cataclysm.ferricdomain


Notice that the bolded and underlined line is a different address (mailman-bounces@mailman.ferricdomain) than the line that is simply bolded (From: Tom . The bolded line is what your mail agent shows you as the sender and is used to reply to (unless the Reply-To: field is set). The bolded and underlined line is the line that SPF acts on.

Now, if your zone is set up with SPF, the SPF-enabled recipient system checks that bolded and underlined line to see if the host that is connecting is allowed to send on behalf of that domain. If it's not, the SPF-enabled system bounces the message. In the end, the address that is only bolded does not play into the SPF bounce decision process. Therefore, mailing lists wont suffer.

-tom

-tom

--
"There are 10 types of people in the world... those who understand binary and those who don't."
"That's only 2 types of people, moron"


callihn4

join:2002-01-10
Space

Why do we need a new way?

What a waste this can already be done and most mail servers handle it just fine, all you have to do is have the server check for an "IN-ARPA.ADDR" entry. If the server does not have a matching "IN-ARPA.ADDR" entry then you can have the mail bounce.

If you are suppose to be sending mail then it will not be a problem getting it set up.
--
If Operating Systems Were Women? : »www.sigkill.com/os/


DrTCP
Yours truly
Premium,ExMod 1999-04
join:1999-11-09
Round Rock, TX

reply to nixen
Re: What

Tom the first from is from SMTP envelope (MAIL FROM). A lot of mail agents will set the same address for envelope and the From: line the same.

You are also asking me to reveal my ISP email address for no reason. I am using a legitimate address and have no connection to spam but I will be victimized by this so-called solution while spammers will find a way around.
Forums » SPF 30?page: 1 · 2


Sunday, 29-Nov 15:40:41 Terms of Use | Privacy Policy | Hosting by www.nac.net - DSL,Hosting & Co-lo | feedback | contact
over 10 years online! © 1999-2009 dslreports.com.
page compression OFF