Hi guys. I notice a large increase in recent weeks of ISP directed phishing - largely because of worms moving backward to using the user's own domain for the spam, but not just in the from: address. I believe this started out as a "let's feel this out" or "wow, that worked, let's phish ISP's directly too". I now have several reports that point to this becoming a serious problem. Old with a spark of new, but definitely a problem. Anyone else dealing with this? Gadi.
At 05:37 AM 6/23/2005, you wrote:
Hi guys. I notice a large increase in recent weeks of ISP directed phishing - largely because of worms moving backward to using the user's own domain for the spam, but not just in the from: address.
I believe this started out as a "let's feel this out" or "wow, that worked, let's phish ISP's directly too". I now have several reports that point to this becoming a serious problem.
Old with a spark of new, but definitely a problem.
Anyone else dealing with this?
Due to the huge number of variants in the wild, our AV software can't keep up (probably nobody's can). Instead, we enabled a global rule which blocks any email from accounts such as billing, root, postmaster, antivirus, abuse, security, etc. which don't originate from our management IP space where our people work. As a result, we have stopped these phishing scams for our users dead in their tracks. -Robert Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com | 888-TELLURIAN | 973-300-9211 "Well done is better than well said." - Benjamin Franklin
Robert Boyle wrote:
At 05:37 AM 6/23/2005, you wrote:
Hi guys. I notice a large increase in recent weeks of ISP directed phishing - largely because of worms moving backward to using the user's own domain for the spam, but not just in the from: address.
I believe this started out as a "let's feel this out" or "wow, that worked, let's phish ISP's directly too". I now have several reports that point to this becoming a serious problem.
Old with a spark of new, but definitely a problem.
Anyone else dealing with this?
Due to the huge number of variants in the wild, our AV software can't keep up (probably nobody's can). Instead, we enabled a global rule which blocks any email from accounts such as billing, root, postmaster, antivirus, abuse, security, etc. which don't originate from our management IP space where our people work. As a result, we have stopped these phishing scams for our users dead in their tracks.
-Robert
We did as well, but we did not yet find a solution for legit bounces.. it naturally breaks that. It's a temporary solution to what I see that is going to become very big.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 23 Jun 2005, Gadi Evron wrote:
Due to the huge number of variants in the wild, our AV software can't keep up (probably nobody's can). Instead, we enabled a global rule which blocks any email from accounts such as billing, root, postmaster, antivirus, abuse, security, etc. which don't originate from our management IP space where our people work. As a result, we have stopped these phishing scams for our users dead in their tracks.
-Robert
We did as well, but we did not yet find a solution for legit bounces.. it naturally breaks that.
It's a temporary solution to what I see that is going to become very big.
The bigger issue is that users simply don't trust any kind of "official communication" anymore and I don't see anything other than pki that could actually restore that. - -- - -------------------------------------------------------------------------- Joel Jaeggli Unix Consulting joelja@darkwing.uoregon.edu GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: pgpenvelope 2.10.2 - http://pgpenvelope.sourceforge.net/ iD8DBQFCuzh+8AA1q7Z/VrIRAoLNAJwIlI+xeEk5TDu22mhGMYVfFIypGACfb2BR /hUazqmv3nleXPriXwuMeSY= =erGj -----END PGP SIGNATURE-----
Joel Jaeggli wrote: <snip>
The bigger issue is that users simply don't trust any kind of "official communication" anymore and I don't see anything other than pki that could actually restore that.
PKI alone won't solve it, but we are not trying to "fix" phishing here (good thought though!). I agree. Thing is, user-trust or no user-trust, they click by the masses. Gadi.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 24 Jun 2005, Gadi Evron wrote:
Joel Jaeggli wrote:
<snip>
The bigger issue is that users simply don't trust any kind of "official communication" anymore and I don't see anything other than pki that could actually restore that.
PKI alone won't solve it, but we are not trying to "fix" phishing here (good thought though!). I agree.
Thing is, user-trust or no user-trust, they click by the masses.
I agree, to elaborate: For us, I see an increasing number of situations where our customers are begining to discard messages we send them about their account because the information we're imparting is hard to distinguish from all the other crap that we don't manage to filter. Claude Shannon could be invoked here. What we have is a noisy communication channel. The phishers are counting on that because the end users are trying to filter all this crap, and the false postive rate of humans trying to distinguish signal from noise is non zero, so eventually people identify the noise as signal. When the noise level gets high enough the signal doesn't get through. There are two solutions really, increase the volume of signal that you send, (basically send more messages) in hopes that get through, apply forward error correction (something that gives the messages a higher likelyhood of being interpreted as signal. If the phishers can replicated the FEC method then the channel gets noisy again.
Gadi.
- -- - -------------------------------------------------------------------------- Joel Jaeggli Unix Consulting joelja@darkwing.uoregon.edu GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: pgpenvelope 2.10.2 - http://pgpenvelope.sourceforge.net/ iD8DBQFCu0118AA1q7Z/VrIRAnGQAJ4rNpG1C+kzSDRwlrJEC+EBWemRmQCfUSjv o467gHoKGCm0JGh0VTvbBE4= =Rq+N -----END PGP SIGNATURE-----
At 10:41 AM 6/23/2005, you wrote:
We did as well, but we did not yet find a solution for legit bounces.. it naturally breaks that.
I've been thinking about what you said, but I can't imagine a scenario in which this would affect bounce delivery to or from our admin-type addresses. Incoming bounces would be from <> and to admin@domain.net. Outgoing bounces would be from <> and to whatever@domain.com. We only block mail sent with the from as one of our admin addresses when it was not sent from our management / customer service / noc address space. If there is a problem which this creates which I haven't thought of, please explain since I would like to eliminate the problem or be aware of it if elimination isn't an option.
It's a temporary solution to what I see that is going to become very big.
x% of people are stupid and will never cease to be stupid. Provided these users are easy enough to reach, they will continue to open naked pictures, free pirated software emailed to them, password protected zip files with really important executables, antivirus "cleaners", microsoft updates from bgates@microsoft.com, 'You gotta see this!' IM URL links from friends, etc. My goal is not to stop stupid people from infecting themselves, but to stop our users from thinking WE infected them by eliminating the one threat vector over which we have absolute control and hence responsibility in the eyes of our customers. "Why did you allow someone to send mail as support@tellurian.net to my account if it had a virus in it?" -Robert Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com | 888-TELLURIAN | 973-300-9211 "Well done is better than well said." - Benjamin Franklin
On Thu, 2005-06-23 at 09:54 -0400, Robert Boyle wrote:
we enabled a global rule which blocks any email from accounts such as billing, root, postmaster, antivirus, abuse, security, etc. which don't originate from our management IP space where our people work. As a result, we have stopped these phishing scams for our users dead in their tracks.
You sound so sure about that... Am I missing something? From: E-gold Safeharbor Department <up-accounts@e-gold.com> Subject: Attention! Your account has been violated! From: "SOUTHTRUST" <support_refnum_2416154@southtrust.com> Subject: SouthTrust Bank: important account notification From: SouthTrust Bank <supprefnum6236641648298@southtrust.com> Subject: SouthTrust Bank: important account notification From: Sky Bank <dindata786@skyfi.com> Subject: Sky Informs You! From: <Andybfboa@UsBank.com> Subject: Anti Fraud Protection against online attacks, UsBank.com update euwtf From: acc-validity@ncua.gov Subject: System maintenance: update your Federal Credit Union Just curious.. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Mark Tombaugh mtombaugh@alliedcc.com Allied Computer Corp Research Triangle Park www.alliedcc.com tel:(919)598-8900 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
At 5:17 PM -0400 2005-06-28, Mark Tombaugh wrote:
On Thu, 2005-06-23 at 09:54 -0400, Robert Boyle wrote:
we enabled a global rule which blocks any email from accounts such as billing, root, postmaster, antivirus, abuse, security, etc. which don't originate from our management IP space where our people work. As a result, we have stopped these phishing scams for our users dead in their tracks.
You sound so sure about that... Am I missing something?
Yes. Any billing, root, postmaster, etc... messages that claim to be from his system have to be generated from their management IP space. You may be able to phish their customers by sending them bogus messages of this sort that claim to be from other sites or facilities, but you won't be able to phish his customers by sending them messages like this that claim to be from his system. I applaud his move, and wish more groups did the same. I recently got hit by a wave of phishing attempts from my own ISP. Unfortunately, the ISP in question refuses to interact with their customers via any method but the web, although they do send out their own notices by e-mail. Of course, none of those accounts will accept bounces or e-mail replies, which is why they're rightfully on the rfc-ignorant black list, among many others. Fortunately for me, all the phishing attempts were pretty stupid, and failed because they relied too much on Windows-specific attacks, Windows-specific MUAs, etc.... -- Brad Knowles, <brad@stop.mail-abuse.org> "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See <http://www.sage.org/> for more info.
On Tue, 28 Jun 2005, Brad Knowles wrote:
At 5:17 PM -0400 2005-06-28, Mark Tombaugh wrote:
On Thu, 2005-06-23 at 09:54 -0400, Robert Boyle wrote:
we enabled a global rule which blocks any email from accounts such as billing, root, postmaster, antivirus, abuse, security, etc. which don't originate from our management IP space where our people work. As a result, we have stopped these phishing scams for our users dead in their tracks.
You sound so sure about that... Am I missing something?
Yes. Any billing, root, postmaster, etc... messages that claim to be from his system have to be generated from their management IP space. You may be able to phish their customers by sending them bogus messages of this sort that claim to be from other sites or facilities, but you won't be able to phish his customers by sending them messages like this that claim to be from his system.
I applaud his move, and wish more groups did the same.
It would have been better if he had just installed SPF, and published DNS records for his own domain, and rejected them based on that. Then other people receiving forged emails with his domain would also be able to just drop those emails. Paul
At 10:30 PM 6/28/2005, Paul Wouters wrote:
I applaud his move, and wish more groups did the same.
It would have been better if he had just installed SPF, and published DNS records for his own domain, and rejected them based on that. Then other people receiving forged emails with his domain would also be able to just drop those emails.
Of course we already do this! Dig before you speak. :) However, we do not filter our customer's email unless they turn on filtering. We tag everything including SPF failures and customers can turn on rejection based solely on SPF failures if they want, but that still doesn't help our users who haven't turned on filtering. Our "admin|root|support|etc" filter previously mentioned in this thread does. We do not have any ethical problem filtering those messages since they are impersonating us. We wouldn't presume that any other mail should be filtered unless a customer requested for us to do so. -Robert Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com | 888-TELLURIAN | 973-300-9211 "Well done is better than well said." - Benjamin Franklin
At 4:30 AM +0200 2005-06-29, Paul Wouters wrote:
It would have been better if he had just installed SPF, and published DNS records for his own domain, and rejected them based on that. Then other people receiving forged emails with his domain would also be able to just drop those emails.
I disagree. Publishing SPF records of that nature would mean that any customers of his who may be roaming would be unable to send e-mail as themselves, and would create the known problems with forwarding. Since you're unlikely to be getting any phishing attempts claiming to come from j-random-user@hisdomains.example.com, the publishing of SPF records in this instance would not do anything measurable to stop spam coming from his systems nor would it have any visible impact on phishing attempts from his systems. SPF is not a panacea. In fact, it is pretty much totally worthless, unless you are the sole owner of a given domain and you can guarantee that all mail you ever send will always be routed through the machines that you own and control, and you know that you don't ever forward e-mail for any of your other accounts. In that case, SPF can be useful to reduce the damage caused by joe-job attacks on you at your domain, but that's about it. And i think you're doing yourself and the entire community a grave disservice by painting SPF as the FUSSP. -- Brad Knowles, <brad@stop.mail-abuse.org> "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See <http://www.sage.org/> for more info.
On Wed, 29 Jun 2005, Brad Knowles wrote:
SPF is not a panacea.
In fact, it is pretty much totally worthless, unless you are the sole owner of a given domain and you can guarantee that all mail you ever send will always be routed through the machines that you own and control, and you know that you don't ever forward e-mail for any of your other accounts.
Actually, what you have to guarantee is that you never send email to anyone who forwards their email elsewhere. This is impossible. Tony. -- f.a.n.finch <dot@dotat.at> http://dotat.at/ BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR GOOD.
On Wed, 29 Jun 2005, Tony Finch wrote:
On Wed, 29 Jun 2005, Brad Knowles wrote:
SPF is not a panacea.
In fact, it is pretty much totally worthless, unless you are the sole owner of a given domain and you can guarantee that all mail you ever send will always be routed through the machines that you own and control, and you know that you don't ever forward e-mail for any of your other accounts.
See my other email in regards to this mobile user strawman argument. Look in the archives for the same arguments against closing open relays.
Actually, what you have to guarantee is that you never send email to anyone who forwards their email elsewhere. This is impossible.
This is incorrect. SPF is an inbound filter. This is in the recipients control, not yours. Assume you send email to alice@alumni.miskatonic.edu and Alice forwards that email address to alice@personaldomain.org. If the inbound mail server for alumni.miskatonic.edu has SPF or MX+ enabled for alice@alumni.miskatonic.edu and and you pass the test and your mail is accepted by alumni.miskatonic.edu then that is the end of your responsibility. If Alice then decides to forward to alice@personaldomain.org and Alice wishes to use SPF or MX+ for the mailbox alice@personaldomain.org as well then Alice would whitelist the IP of the outbound mail server for alumni.miskatonic.edu. You don't have control over what forwarding, filtering, or whitelisting Alice does with her personal mailbox. If Alice wants to forward alice@alumni.miskatonic.edu to alice@personaldomain.org and use SPF or MX+ with alice@personaldomain.org presumably she won't block email from her other account and she can check if she got it right really easy by sending email to alice@alumni.miskatonic.edu. +----------------- H U R R I C A N E - E L E C T R I C -----------------+ | Mike Leber Direct Internet Connections Voice 510 580 4100 | | Hurricane Electric Web Hosting Colocation Fax 510 580 4151 | | mleber@he.net http://www.he.net | +-----------------------------------------------------------------------+
On 29/06/05, Mike Leber <mleber@he.net> wrote:
You don't have control over what forwarding, filtering, or whitelisting Alice does with her personal mailbox.
Actually Alice doesnt have control over her ISP who believes that kool aid about path authentication being a silver bullet and rejects wholesale based on spf failures (sometimes treating ~all or ?all as equivalent to -all) -srs
Suresh Ramasubramanian <ops.lists@gmail.com> wrote: [...]
Actually Alice doesnt have control over her ISP who believes that kool aid about path authentication being a silver bullet and rejects wholesale based on spf failures (sometimes treating ~all or ?all as equivalent to -all)
Sure Alice has control. Last week, I told my ISP where to stick their shoddy service and took my business elsewhere. -- PGP key ID E85DC776 - finger abuse@mooli.org.uk for full key Please contribute to the beer fund and a tidier house: http://search.ebay.co.uk/_W0QQfgtpZ1QQfrppZ25QQsassZpndc
At 12:20 PM +0000 2005-06-29, Peter Corlett wrote:
Sure Alice has control. Last week, I told my ISP where to stick their shoddy service and took my business elsewhere.
You're assuming that there are always alternatives available for the entire world population. While there may usually be alternatives available in the most advanced western societies, you would be surprised at the types of places where you would think that there have to be alternatives, but in fact there aren't any. The solution that may work reasonably well for NYC or LA is not necessarily going to be applicable to the rest of the world. -- Brad Knowles, <brad@stop.mail-abuse.org> "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See <http://www.sage.org/> for more info.
On Wed, 29 Jun 2005, Mike Leber wrote:
See my other email in regards to this mobile user strawman argument. Look in the archives for the same arguments against closing open relays.
Current mobile-user arguments against SPF do indeed remind of the anti open-relay battles 5-8 years ago. Not only that but often enough its the same people who are doing this arguing ... (just look at the main ietf mail list and you'll see what I mean).
If Alice wants to forward alice@alumni.miskatonic.edu to alice@personaldomain.org and use SPF or MX+ with alice@personaldomain.org presumably she won't block email from her other account and she can check if she got it right really easy by sending email to alice@alumni.miskatonic.edu.
Unfortunately per-user filters for SMTP transmission are notoriously difficult to implement (especially on large scale). Plus you may not be able to say that email came in forwarded just from SMTP transmission (forwarders often do not leave its own marker, you can try to identify forwarder by EHLO name but that may not be forwarder by some kind of outbound relay server on the forwarding network site). Another issue is that are doing the forwarding are the ones that are most often least maintained as far as upgrading software and enabling new SMTP features. As a result an idea that we will ask all forwarders to change and identify themselves in forwarded mail can not happen as quickly as path authentication proponents want. Now I did propose one solution to this - a way to bypass forwarders by having origin mail servers add crypto signatures with their own hostname serving as base and then tie in further path authentication to cryptographically verified hostname (see paper, I previously posted, quick link at http://purl.org/NET/pacap), and I have more hope in another system that I'll get to later this year. -- William Leibzon Elan Networks william@elan.net
On 29/06/05, william(at)elan.net <william@elan.net> wrote:
Another issue is that are doing the forwarding are the ones that are most often least maintained as far as upgrading software and enabling new SMTP features. As a result an idea that we will ask all forwarders to change and identify themselves in forwarded mail can not happen as quickly as path authentication proponents want.
Please name a few names on just who is not enabling "new smtp features" And what "smtp features" you'd like enabled. RFC 2822 / ESMTP hasnt changed all that much, and then there's SES, which if you call an SMTP feature, I'd beg to differ on that ..
On Wed, 29 Jun 2005, Suresh Ramasubramanian wrote:
On 29/06/05, william(at)elan.net <william@elan.net> wrote:
Another issue is that are doing the forwarding are the ones that are most often least maintained as far as upgrading software and enabling new SMTP features. As a result an idea that we will ask all forwarders to change and identify themselves in forwarded mail can not happen as quickly as path authentication proponents want.
Please name a few names on just who is not enabling "new smtp features"
And what "smtp features" you'd like enabled. RFC 2822 / ESMTP hasnt changed all that much, and then there's SES, which if you call an SMTP feature, I'd beg to differ on that ..
DSN are not supported and that is important as far as forwarding goes. 8BITMIME and BINARYMIME are rarely supported. Also don't confuse SES with SRS. SES is specification of crypt signatures in RFC2821 MAILFROM and should not be added by forwarders. As to who, I don't want to put names but many (I'd go as far as to say majority, but we'd need statistical study) university forwarding servers for alumni forwarding run smtp software 5+ years old (they don't really need much more then just to look at aliases of forwarding db and send email further - once setup this system works for long time). Many small companies with email forwarding setup forwarding setup for few old employers or for subdivisions they previously bought also have problems. BTW - I happened to know person who has setup email forwarding for his department in major university in st.louis on sparc2 12 years ago. It is still working as far as I know! Last mail software update on it I believe was made 5 or 6 years ago when open relaying was disabled. -- William Leibzon Elan Networks william@elan.net
On 29/06/05, william(at)elan.net <william@elan.net> wrote:
BTW - I happened to know person who has setup email forwarding for his department in major university in st.louis on sparc2 12 years ago. It is still working as far as I know! Last mail software update on it I believe was made 5 or 6 years ago when open relaying was disabled.
We dont do sender rewriting / envelope rewriting for forwarded email, just pass it on We'll prepend Resent: headers though .. that should be enough But well, we run linux and postfix, and a reasonably recent (non bleeding edge) version of both. We're not running on sendmail 8.8.8 or whatever your university department friend was running, I assure you -- Suresh Ramasubramanian (ops.lists@gmail.com)
On Wed, 29 Jun 2005, Suresh Ramasubramanian wrote:
We dont do sender rewriting / envelope rewriting for forwarded email, just pass it on We'll prepend Resent: headers though .. that should be enough
That's not permitted by RFC 2822 and it'll cause interoperability problems with software that only implements RFC 822 Resent- semantics (only one group of Resent- fields). AFAIK most software that understands Resent- fields does not understand RFC 2822 multiple Resent- groups. Tony. -- f.a.n.finch <dot@dotat.at> http://dotat.at/ BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR GOOD.
On Wed, 29 Jun 2005, Suresh Ramasubramanian wrote:
On 29/06/05, william(at)elan.net <william@elan.net> wrote:
BTW - I happened to know person who has setup email forwarding for his department in major university in st.louis on sparc2 12 years ago. It is still working as far as I know! Last mail software update on it I believe was made 5 or 6 years ago when open relaying was disabled.
We dont do sender rewriting / envelope rewriting for forwarded email, just pass it on
We'll prepend Resent: headers though .. that should be enough
And that would like be against what is specified in RFC2822 as in section 3.6.6 it says: ---------------------------------------------------------------------- Note: Reintroducing a message into the transport system and using resent fields is a different operation from "forwarding". "Forwarding" has two meanings: One sense of forwarding is that a mail reading program can be told by a user to forward a copy of a message to another person, making the forwarded message the body of the new message. A forwarded message in this sense does not appear to have come from the original sender, but is an entirely new message from the forwarder of the message. On the other hand, forwarding is also used to mean when a mail transport program gets a message and forwards it on to a different destination for final delivery. Resent header fields are not intended for use with either type of forwarding. ---------------------------------------------------------------------- You really should not be using Resent- unless this is done from MUA by direct manual action of the user - but use of Resent- by automated MTA process is not ok.
But well, we run linux and postfix, and a reasonably recent (non bleeding edge) version of both. We're not running on sendmail 8.8.8 or whatever your university department friend was running, I assure you
The point is that there are many systems setup all over the world and people don't realize how many of those small intermediate systems are out there that are not running recent mail software. And because for forwarding systems setup many do not need to do more then relay to pre-defined address from aliases file or database, there is little need to to keep system updated to latest standards and this creates a very big problem as far as getting every forwarding system updated fast with something like SRS. -- William Leibzon Elan Networks william@elan.net
Tony Finch <dot@dotat.at> wrote: [...]
Actually, what you have to guarantee is that you never send email to anyone who forwards their email elsewhere. This is impossible.
How do you figure that? The failure mode in this case is if somebody arranges "dumb" mail forwarding that doesn't do envelope rewriting, and also applies a SPF filter on their incoming mail. The problem is quite clearly of the recipient's making rather than any fault of the sender's. -- When I told the people of Northern Ireland that I was an atheist, a woman in the audience stood up and said, 'Yes, but is it the God of the Catholics or the God of the Protestants in whom you don't believe? - Quentin Crisp
On Wed, 29 Jun 2005, Peter Corlett wrote:
Tony Finch <dot@dotat.at> wrote: [...]
Actually, what you have to guarantee is that you never send email to anyone who forwards their email elsewhere. This is impossible.
How do you figure that?
The failure mode in this case is if somebody arranges "dumb" mail forwarding that doesn't do envelope rewriting, and also applies a SPF filter on their incoming mail. The problem is quite clearly of the recipient's making rather than any fault of the sender's.
Most forwarding services do nothing but change the envelope recipient address, and this has been standard practice for many many years. Sites that do SPF checking on incoming email must take this into account if their users forward email from elsewhere. However most sites do not do so, partly because the SPF documentation doesn't make it clear that they must, and partly because it's basically impossible - for every user that forwards email to your site you must whitelist the IP addresses of the forwarding mail servers, and you can't find out what those IP addresses are or when they change. So if a site that checks SPF can't work around the forwarding problem, can a site that publishes SPF? No, because a sender at a publishing site can't find out if a recipient is suffering from this breakage. The only solution is for the SPF checking recipient site to make it clear to their users that they must not forward email from elsewhere. However most sites do not do this. Tony. -- f.a.n.finch <dot@dotat.at> http://dotat.at/ BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR GOOD.
* dot@dotat.at (Tony Finch) [Wed 29 Jun 2005, 15:28 CEST]:
Tony Finch <dot@dotat.at> wrote: [...]
Actually, what you have to guarantee is that you never send email to anyone who forwards their email elsewhere. This is impossible. How do you figure that?
The failure mode in this case is if somebody arranges "dumb" mail forwarding that doesn't do envelope rewriting, and also applies a SPF filter on their incoming mail. The problem is quite clearly of the recipient's making rather than any fault of the sender's. Most forwarding services do nothing but change the envelope recipient address, and this has been standard practice for many many years. Sites
On Wed, 29 Jun 2005, Peter Corlett wrote: that do SPF checking on incoming email must take this into account if their users forward email from elsewhere. However most sites do not do so, partly because the SPF documentation doesn't make it clear that they must, and partly because it's basically impossible - for every user that forwards email to your site you must whitelist the IP addresses of the forwarding mail servers, and you can't find out what those IP addresses are or when they change.
How do I configure my router for that? -- Niels. -- The idle mind is the devil's playground
On Wed, 29 Jun 2005, Peter Corlett wrote:
Actually, what you have to guarantee is that you never send email to anyone who forwards their email elsewhere. This is impossible.
How do you figure that?
The failure mode in this case is if somebody arranges "dumb" mail forwarding that doesn't do envelope rewriting, and also applies a SPF filter on their incoming mail.
Actually, that's not quite right. The failure mode is if someone arranges no-rewrite mail forwarding, and mail is sent through that forwarding host from a domain with a published SPF record ending in "-all". Or, to put it in steps: 1. foo@one.example.com sends a mail to bar@two.example.com. "one.example.com" has a SPF record ending in "-all", but the mail at this point is coming from a SPF-pass host. 2. bar@two.example.com is a dumb forward to baz@three.example.com. The mail from foo@one.example.com is now coming from an SPF-fail host. 3. baz@three.example.com has SPF filtering turned on. It receives the mail attempt from foo@one.example.com, but the SPF test fails authoritatively. The mail is blocked. This is the single external dependency problem with SPF, such that forwarding accounts that do not employ SRS or similar botch the whole scheme. As a result, many end hosts have started putting in local SPF exceptions for some forwarding hosts that do not implement sender rewriting. However, many popular forwarding account systems (particularly large ones like pobox.com and mail.com) have awakened to the failure mode in step 2. These hosts have either implemented SRS, or changed the envelope-from on forwarded mail to be something like the forwarding account itself (with loop detection) or postmaster@. -- -- Todd Vierling <tv@duh.org> <tv@pobox.com> <todd@vierling.name>
On Tue, Jun 28, 2005 at 04:35:30PM -0500, Brad Knowles wrote:
Fortunately for me, all the phishing attempts were pretty stupid, and failed because they relied too much on Windows-specific attacks, Windows-specific MUAs, etc....
In my case they were merely amusing. If there *were* an admin@baylink.com... it'd be me. Good to see some people are trying, though... Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Designer +-Internetworking------+----------+ RFC 2100 Ashworth & Associates | Best Practices Wiki | | '87 e24 St Petersburg FL USA http://bestpractices.wikicities.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
At 05:17 PM 6/28/2005, Mark Tombaugh wrote:
On Thu, 2005-06-23 at 09:54 -0400, Robert Boyle wrote:
we enabled a global rule which blocks any email from accounts such as billing, root, postmaster, antivirus, abuse, security, etc. which don't originate from our management IP space where our people work. As a result, we have stopped these phishing scams for our users dead in their tracks.
You sound so sure about that... Am I missing something?
From: E-gold Safeharbor Department <up-accounts@e-gold.com> Subject: Attention! Your account has been violated!
From: "SOUTHTRUST" <support_refnum_2416154@southtrust.com> Subject: SouthTrust Bank: important account notification
We have stopped the phishing which looks like it is from us(tellurian.net/tellurian.com/garden.net). Not from "their" bank, paypal, ebay, credit card companies, etc. Our main concern was with messages which looked like they were from support@tellurian.net telling people there was a problem with their email and they have to run this file or a problem with their account payment from billing@tellurian.net and the details were in the attached file. To the novice user, it may look legitimate since we are their ISP and with that comes a certain amount of trust - despite the fact that we would never send files to our customers and tell them to run them. However, the spoofed messages from us have completely stopped now. The regular phishing scams continue, but SPF does help with this if the customers have turned it on for their account. Unfortunately, the customers smart enough to turn it on usually won't be suckered by phishing scams in the first place. -Robert Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com | 888-TELLURIAN | 973-300-9211 "Well done is better than well said." - Benjamin Franklin
participants (16)
-
abuse＠cabal.org.uk -
Brad Knowles -
Gadi Evron -
Gadi Evron -
Jay R. Ashworth -
Joel Jaeggli -
Mark Tombaugh -
Mike Leber -
Niels Bakker -
Paul Wouters -
Robert Boyle -
Suresh Ramasubramanian -
Todd Vierling -
Tony Finch -
Valdis.Kletnieks＠vt.edu -
william(at)elan.net