SPF 30?Mail authentication standard spreads ( old news - 06:39PM Thursday Jan 22 2004) tags: business · security · spamOn 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 preventing spoofing. SPF is an open-standard mail delivery enhancement that aims to do something traditional mail delivery systems alone were never completely designed to do: detect and verify that an IP address/sender is authorized to be sending mail from that domain. To solve the spam problem, some have suggested an overhaul of SMTP is necessary, while others look toward projects like SPF as a partial cure. Other concepts such as Designated Mailers Protocol (DMP) and Reverse Mail Exchange (RMX) have brought similar ideas to the table. Last fall the Anti-Spam Research Group of the Internet Research Task Force was tasked with taking all of these competing protocols and integrating them into one standard. All were designed to modify the Domain Name System database, allowing mail servers to publish what IP addresses are associated with them via a registry. ISP's then check the registry to verify that the e-mail has a legitimate origin. If a sender's IP address isn't authorized to be using that domain, the mail may be blocked completely or tagged as bulk mail. The end result is not entirely unlike a considerably more vague caller-id system for e-mail, assuming the standard is adopted by numerous providers. According to Eric Raymond, president of the Open Source Initiative, more than 4,000 domains have already published their SPF records. That now includes AOL, who this month became the largest provider to adopt SPF as part of their spam solution. Like every anti-spam solution from blacklists to legislation, this latest approach has no shortage of critics and supporters. The SPF FAQ explains the basics behind the idea, while the website also takes time to answer the the most common concerns about the concept. There's also a comparison of SPF, RMX and DMP. AOL implementing the standard could mean big things insofar as a broad community adoption of SPF. Like Yahoo's Domain Keys, scattered adoption of these standards is hardly as effective as broader community integration.
Related:- Qwest Employs New Malware Security
- As Expected, Huge Spam Reduction To Be Short Lived
- Microsoft Discontinuing OneCare
- McColo Closure Forces BotNet Shift
- Srizbi Botnet Servers Flee To Estonia
- Can Spam Act Celebrates Five Years Of Ineffectiveness
- 37% Of Malware Originates In U.S.
- Google #4 On Spamhaus Spam Network List
|
 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
edit:
January 22nd, @04:25PM
| Re: AOL doing something for EMAIL spam 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
edit:
January 22nd, @04:33PM
| 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
| Re: Mailing Lists said by Morac  :
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. | |
| | | jester121
join:2003-08-09
Lake Zurich, IL | 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
|  We'll see...
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. | |
| |
graysonf
Premium,MVM
join:1999-07-16
Fort Lauderdale, FL
| 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. | |
| | |
ChrisDAT
Google Keyword Compsysnyc
join:2002-02-26
Hollis, NY
| 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. | |
| | | |
graysonf
Premium,MVM
join:1999-07-16
Fort Lauderdale, FL
| Re: We'll see... 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. | |
| | | JimF
join:2003-06-15
Allentown, PA
| 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. | |
| 
cyberthugin
join:2002-03-12
Kew Gardens, NY
|  What
--
www.alltechneeds.com
"Your Everyday Hosting Needs" | |
| | | | | | | 
nixen
Rockin' the Boxen
Premium
join:2002-10-04
Alexandria, VA
·Cox HSI
 ·Speakeasy
| said by cyberthugin :
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 from152.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
| Re: What 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... | |
| | | |
nixen
Rockin' the Boxen
Premium
join:2002-10-04
Alexandria, VA
·Cox HSI
·Speakeasy
| Re: WhatThis 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" | |
| | | | |
DrTCP
Yours truly
Premium,ExMod 1999-04
join:1999-11-09
Round Rock, TX
| 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. | |
| | | | | |
nixen
Rockin' the Boxen
Premium
join:2002-10-04
Alexandria, VA
·Cox HSI
·Speakeasy
edit:
January 23rd, @11:51AM
| Re: What said by DrTCP :
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.
My reply was regarding mailing lists. Mailing lists will have their envelope "From " address be that of the mailing list user (i.e., mailistname@maillist.server.domain). SPF would not interfere with such traffic, even if the "From:" address is that of one of the maillist subscribers.
said by DrTCP :
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.
I'm not really asking you to do anything. However, if you're going to have a vanity domain and if you're going to participate in SPF, then you need to make sure that there's a DNS record for your domain name that lists your ISP's mail server as a valid originating host.
ISPs that use SPF can then decide, when receiving mail from you, what to do with the email.
•If your @domain.com is SPF-enabled and the mail connection is coming from an SMTP relay that is registered as being authorized to send for your domain, you are golden.
•If your @domain.com is SPF-enabled and the mail connection is coming from an SMTP relay that is not registered as being authorized to send for your domain, only then will the email get rejected.
•If your @domain.com is not SPF-enabled, then the ISP that's using SPF has to make policy decisions about accepting, rejecting or tagging your email. Most will probably simply tag your email (or lower it's precedence level)
Frankly, I don't see the undue burden on you. If you have a personal domain, you have to get DNS service done any way. Having your DNS provider add an SPF record should be no big deal. And, if you change ISPs, you're going to have to get your MX records changed any way - where's the burden in getting a TXT record changed when you are already getting MX records changed?
-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
| Re: What said by nixen :
I'm not really asking you to do anything. However, if you're going to have a vanity domain and if you're going to participate in SPF, then you need to make sure that there's a DNS record for your domain name that lists your ISP's mail server as a valid originating host.
I can do that since I own the domain but when travelling I cannot do that. Adding the SMTP server to the domain records does not take effect immediately if the domain was cached.
Some registrars do not allow TXT records. This would cause me to move the domain services to another location or actually host my own (which is contary to hosting outside)
Also, I am lucky to own this domain which means I have some workarounds you have pointed. But a lot of people using just another email address (say their work or another provider) will be banned by this scheme. ISP's will start milking money from customers to provide this.
As it is demonstarted the spammer will simply pick a dummy email address that is belonging to the domain they are sending from and their problem will be solved while average user will be inconvenienced.
quote:
Frankly, I don't see the undue burden on you. If you have a personal domain, you have to get DNS service done any way. Having your DNS provider add an SPF record should be no big deal.
Don't make assumption. A lot of DNS providers do not expose TXT records.
quote:
And, if you change ISPs, you're going to have to get your MX records changed any way - where's the burden in getting a TXT record changed when you are already getting MX records changed?
No, I do not change MX records when I change my ISP. I actually do not do anything other than changing SMTP server address settings of my email client. I only have to change MX settings if I move my hosting provider which is not my ISP.
Signed email using user certificates is actually a better solution. Certificates are portable and the identity of the sender can be verified individually instead of binding the user with the ISP as this current scheme does.
The actual solution will come when Internet moves to signed mail instead. All others are really hacks and they break normal flow of operations one way or another.
Right not I do not need to communicate with AOL users. If AOL users want to get email from me they can use another account. | |
| | | | | | | |
nixen
Rockin' the Boxen
Premium
join:2002-10-04
Alexandria, VA
·Cox HSI
·Speakeasy
| Re: What said by DrTCP :
said by nixen :
I'm not really asking you to do anything. However, if you're going to have a vanity domain and if you're going to participate in SPF, then you need to make sure that there's a DNS record for your domain name that lists your ISP's mail server as a valid originating host.
I can do that since I own the domain but when travelling I cannot do that.
Err... What?? SPF is for MTAs, not SMTP clients. In fact, it's designed to stop random clients from being able to directly send mail (as happens when a worm installs an SMTP engine to do its dirty work). No matter where you are, at home, at the office or on the road, you configure your SMTP client to attach to an MTA that is authorized to send emails on behalf of your user address. Unless your SMTP relay provider is completely addle-brained, they require authentication to relay in the first place.
said by DrTCP :
Adding the SMTP server to the domain records does not take effect immediately if the domain was cached.
1. What the heck would this have to do with ANYTHING,
2. Domains don't get cached, records do. Such that, if
a lookup was performed and there was previously a
failure to find the record, there would be nothing to
cache or prevent subsequent lookups. As soon as the
record is created, it is immediately available for the
next lookup request.
said by DrTCP :
Some registrars do not allow TXT records.
Kind of immaterial whether a registrar allows TXT records. If your DNS provider doesn't provide full service, then maybe you should reconsider your choice of DNS provider.
said by DrTCP :
This would cause me to move the domain services to another location or actually host my own (which is contary to hosting outside)
Only if this ever became anything that was mandatory.
However, SPF is mostly designed to be advisory. That is to say, if SPF tests pass, then the traffic is considered to be from an authentic source. If the tests fail, it's considered to be forged. If the tests are done against a non-participating domain, then they simply get passed as not authenticated and given an advisory tag (that can be used for filtering purposes).
said by DrTCP :
Also, I am lucky to own this domain which means I have some workarounds you have pointed. But a lot of people using just another email address (say their work or another provider) will be banned by this scheme. ISP's will start milking money from customers to provide this.
I REALLY get the impression that you've failed to read SPF's documentation...
said by DrTCP :
As it is demonstarted the spammer will simply pick a dummy email address that is belonging to the domain they are sending from and their problem will be solved while average user will be inconvenienced.
Ok... So you're saying, "it's a bad thing that someone claiming to be mailing from @aol.com is, in fact, originating from aol.com"? You're saying it's a bad thing to be able to easily and reliably track back the source of a piece of email to a given ISP?
Aside from that is the fact that, if implemented correctly, the ISPs that chose to use SPF will require authenticated SMTP transactions. That means, that they can then track a particular email to a particular subscriber. In other words, even if it's an ISP with tens of millions of subscribers, only one user should have a given set of credentials. That would be traceable and therefore squelch-able.
said by DrTCP :
No, I do not change MX records when I change my ISP. I actually do not do anything other than changing SMTP server address settings of my email client.
Just your SMTP server address settings? No changes to authentication parameters? If that's the case, you deal with crap SMTP service providers.
said by DrTCP :
Signed email using user certificates is actually a better solution. Certificates are portable and the identity of the sender can be verified individually instead of binding the user with the ISP as this current scheme does.
That's a crap argument. All it takes is for your computer to get infected with something that reads your certificate store and then viral emails get sent using your authentication credentials and your signature. Certificates solve only one thing: verifying that an email originated from the system(s) that the certificate was installed on (which can be accomplished with simple user/password schemes). It doesn't prove that the certificate's human owner actually sent anything.
By itself, certificates do not and will not prevent SPAM. Now, if you take certificates to provide an authenticated user/sender and you use something like SPF to provide an authenticated SMTP source path, you begin to be able to make an end-to-end verified mail path. You remove the SPAMmers ability to hide. Without such a verified path, without removing the ability to hide, SPAM will continue.
said by DrTCP :
Right not I do not need to communicate with AOL users. If AOL users want to get email from me they can use another account.
Again, statements like the above REALLY gives the impression that you've failed to read (or at least comprehend) SPF's documentation...
-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
| Re: What said by nixen :
Err... What?? SPF is for MTAs, not SMTP clients. In fact, it's designed to stop random clients from being able to directly send mail (as happens when a worm installs an SMTP engine to do its dirty work). No matter where you are, at home, at the office or on the road, you configure your SMTP client to attach to an MTA that is authorized to send emails on behalf of your user address.
Some locations are behind firewalls that limit accesses to outbound port 25 access. So, you will have to deal with the SMTP server provided by that location. Access to authorized MTA is not possible.
quote:
Unless your SMTP relay provider is completely addle-brained, they require authentication to relay in the first place.
That is fine. But, original domain where your email address belongs will not necessarily agree to add the MTA you are forced to use as "Authorized MTA" for that domain. If you are owner of the domain this is not a problem. If not you have no hope of sending email from that location while on the move.
quote:
said by DrTCP :
Adding the SMTP server to the domain records does not take effect immediately if the domain was cached.
1. What the heck would this have to do with ANYTHING,
2. Domains don't get cached, records do. Such that, if
a lookup was performed and there was previously a
failure to find the record, there would be nothing to
cache or prevent subsequent lookups. As soon as the
record is created, it is immediately available for the
next lookup request.
Obviously I meant records by domain caching. If the older TXT records were cached for you will have to wait until the TTL expires.
quote:
said by DrTCP :
Some registrars do not allow TXT records.
Kind of immaterial whether a registrar allows TXT records. If your DNS provider doesn't provide full service, then maybe you should reconsider your choice of DNS provider.
Nevertheless it is a fact. SPF is supposed to play nice. Use of TXT records were discouraged if you check many BIND/DNS documentation.
quote:
said by DrTCP :
This would cause me to move the domain services to another location or actually host my own (which is contary to hosting outside)
Only if this ever became anything that was mandatory.
Don't get me started about it not being mandatory. It will be a matter of moment before AOL etc. will move not to except mail from anyone unless they publish SPF records.
quote:
However, SPF is mostly designed to be advisory.
BS! I am afraid the application and use will be far from it.
quote:
That is to say, if SPF tests pass, then the traffic is considered to be from an authentic source. If the tests fail, it's considered to be forged. If the tests are done against a non-participating domain, then they simply get passed as not authenticated and given an advisory tag (that can be used for filtering purposes).
Or, instead of that advisory tag it will be just dropped and this everyone will be forced to it...
quote:
get the impression that you've failed to read SPF's documentation...
I read it all. You guys are trying to sugar coating everything about it by undermining major issues.
quote:
Ok... So you're saying, "it's a bad thing that someone claiming to be mailing from @aol.com is, in fact, originating from aol.com"? You're saying it's a bad thing to be able to easily and reliably track back the source of a piece of email to a given ISP?
ISP is not important. You really want to track it to the individual in the first place.
quote:
said by DrTCP :
No, I do not change MX records when I change my ISP. I actually do not do anything other than changing SMTP server address settings of my email client.
Just your SMTP server address settings? No changes to authentication parameters? If that's the case, you deal with crap SMTP service providers.
If necessary SMTP service provider authentication parameters can be set as well. However, some large providers like RoadRunner, Earthlink etc. with a large market share of Internet business do not use Authentication to use their outgoing mail server if you are coming from their IPs. I.e. relaying is open for their own IP ranges.
quote:
said by DrTCP :
Signed email using user certificates is actually a better solution. Certificates are portable and the identity of the sender can be verified individually instead of binding the user with the ISP as this current scheme does.
That's a crap argument. All it takes is for your computer to get infected with something that reads your certificate store and then viral emails get sent using your authentication credentials and your signature.
You are responsible for your own signing keys. The certificate can be revoked as well.
quote:
Certificates solve only one thing: verifying that an email originated from the system(s) that the certificate was installed on (which can be accomplished with simple user/password schemes). It doesn't prove that the certificate's human owner actually sent anything.
Every heard about user certificates. I am not talking about system certificates here. You will own certificates for each email address. You can use your certificate at a different location (or your certificate can be stored in a SIM card).
quote:
By itself, certificates do not and will not prevent SPAM. Now, if you take certificates to provide an authenticated user/sender and you use something like SPF to provide an authenticated SMTP source path, you begin to be able to make an end-to-end verified mail path. You remove the SPAMmers ability to hide. Without such a verified path, without removing the ability to hide, SPAM will continue.
User certificates prevent SPAM'ers ability to hide and they are portable. SPF does not authenticate the user. It just authenticates the MTA against the domain the user is claiming to be. It is not exactly on the target.
quote:
said by DrTCP :
Right not I do not need to communicate with AOL users. If AOL users want to get email from me they can use another account.
Again, statements like the above REALLY gives the impression that you've failed to read (or at least comprehend) SPF's documentation...
I read it. If AOL decides to make participation in SPF obligatory to send mail to AOL users in the future, I do not care if AOL users actually receive mail from my domain. They can live in their crippled BBS world anyway.
I understand how it is supposed to work perfectly. I also see a lot of practical problems about it which you guys conveniently undermine and sugar coat. I guess we will agree to disagree.
I use safe email practices and the amount of spam I get is very limited as a result. Don't use your main email address on every form. I use temporary email addresses extensively and once my correspondence is done I delete the email address. Thus spam that gets through is very limited and user side filtering takes care of the rest. | |
| | | | | snkeyes3
join:2003-09-23
edit:
January 23rd, @10:27AM
| Let me see if I understand you correctly...
I can't afford to host my own e-mail and website. My website and e-mail (mybusiness.com) are hosted by my favorite mom & pop ISP (localisp.com). All e-mail sent to mybusiness.com addresses (for example mybusiness@mybusiness.com) ends up in my localisp.com mailbox (mybusiness@localisp.com). When I check e-mail, I only log into my localisp.com mailbox (mybusiness@localisp.com).
Roadrunner is offering broadband service for $99. But, localisp.com wants a LOT more money for broadband access. So, I get Roadrunner. I send e-mail out using smtp.myarea.rr.com. But, my pop3 server is still mail.localisp.com. People still send me e-mail at mybusiness@mybusiness.com. I still receive their e-mail at mybusiness@localisp.com, I just check it from Roadrunner now.
Are you saying that...as long as I send e-mail from my Roadrunner IP address through my assigned Roadrunner SMTP server (smtp.myarea.rr.com), my e-mail will not be blocked, even though my "sender" (mybusiness@mybusiness.com) and "reply to" (mybusiness@mybusiness.com) fields are not Roadrunner?
On the flip side, a spammer sends e-mail from Roadrunner through an SMTP server in China. Will his spam be caught because his IP address is not on the Chinese SMTP server's list?
Assuming this is true, what's to stop a spammer from getting a throw-away e-mail account and sending spam through the smtp server of their current ISP? This may make it easier to track down some spammers, but what about the ones using dial-up accounts purchased with stolen credit cards, etc... What about viruses designed to take advantage of this behavior? Is this a real solution, or just a poorly fitting band-aid? | |
| | | | | |
DrTCP
Yours truly
Premium,ExMod 1999-04
join:1999-11-09
Round Rock, TX
| Re: What said by snkeyes3 :
Let me see if I understand you correctly...
I can't afford to host my own e-mail and website. My website and e-mail (mybusiness.com) are hosted by my favorite mom & pop ISP (localisp.com). All e-mail sent to mybusiness.com addresses (for example mybusiness@mybusiness.com) ends up in my localisp.com mailbox (mybusiness@localisp.com). When I check e-mail, I only log into my localisp.com mailbox (mybusiness@localisp.com).
Roadrunner is offering broadband service for $99. But, localisp.com wants a LOT more money for broadband access. So, I get Roadrunner. I send e-mail out using smtp.myarea.rr.com. But, my pop3 server is still mail.localisp.com. People still send me e-mail at mybusiness@mybusiness.com. I still receive their e-mail at mybusiness@localisp.com, I just check it from Roadrunner now.
This is exactly what I am doing. I do not use the ISP supplied email addresses because their service has been so unreliable for me and using my own domain gives me ISP portability (I am no longer stuck with them. I can change my ISP easily without effecting my connections)
quote:
Are you saying that...as long as I send e-mail from my Roadrunner IP address through my assigned Roadrunner SMTP server (smtp.myarea.rr.com), my e-mail will not be blocked, even though my "sender" (mybusiness@mybusiness.com) and "reply to" (mybusiness@mybusiness.com) fields are not Roadrunner?
It will be blocked if the SMTP envolope address appears to be that off the ISP. Many mail agents simply use the same address in From: header line as the SMTP envelope so this will block your legitimate mail as well.
It is also easy for spammers to fool the system by just making fake SMTP mail addresses that contain the domain of the ISP they are sending from. | |
| 
Theo25
@attbi.com | Great To See This Its great to see them stepping up to do something about this. | |
| 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. | |
| 
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/ | |
| 
ncherry
Premium
join:2003-07-13
Monroe Township, NJ
·Comcast
| Isn't SPAM coming from end user works stations? I'm finding all of this a bit humorous as I think that the new group of SPAM/Virus/Trojan stuff simply gets sent from an end user work station. Doesn't this bypass SPAMMERs to mail servers for the most part. The SPAM looks like mail sent by the user (their machine is a SPAM zombie) to the ISP mail server. At least this is what I'm seeing as most of the SPAM I receive as an end user.
--
Neil Cherry - Linux Home Automation - Linux Home Automation | |
| |
Coolbird720
@swbell.ne
| Re: Blocking That's really almost impossible to do since sometimes they put hyphens or other characters in the message. What I do is filter all those that I know and put them in special folders. Anything that comes into the inbox of my main e-mail program is usually spam.
Now I've got a problem. After I delete spammed mail to me, they bounce that back to me, making it look like I'm the spammer, when I'm not. It's so frustrating, and I don't know what to do about that. | |
| | | |
|
|
Re: What
How can i pass ISP blocking of some sites like "sex"