how-to block ads
|
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" | |
ChrisDAT
Google Keyword Compsysnyc
join:2002-02-26
Hollis, NY
| said by cyberthugin  :
...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 | |
Vvian Kalyss
join:2003-10-14
Stage 5.0
clubs:
|  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 :
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
| 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
| 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" | |
DrTCP
Yours truly
Premium,ExMod 1999-04
join:1999-11-09
Round Rock, TX
| 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. | |
snkeyes3
join:2003-09-23
2 edits | reply to nixen
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
| 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. | |
nixen
Rockin' the Boxen
Premium
join:2002-10-04
Alexandria, VA
·Cox HSI
·Speakeasy
1 edit | reply to DrTCP
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
| 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
| 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
| 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. | |
|
