Editing NonMaliciousForging
Help Page
|
Text Formatting Rules
|
HTML Basics
NON-MALICIOUS FORGING Categories of non-malicious forging I have observed: a. Consumer-level consensual forging b. 3rd party consensual forging - not joejob-able: c. Joejob-able "consensual" forging: d. Account redirection or account forwarding forging Before I give examples of what I mean by each... I agree with <a href="http://spf.pobox.com/">Meng Wong</A>, that it is reasonable to expect a change in behavior from those who presently forge for non-malicious reasons, and that education + reality will create this change. I also believe there is not even a lot of pain involved, and that Meng is right that small reasonable shifts in exchange for substantial relief from spam, will be supported by both consumers and ISPs in the near future. If, as a consumer level user, I want to send mail anonymously, I can still select an email ISP or domain which "authorizes all SMTPs." Yes, that mail may someday soon be treated with the same level of scrutiny and special treatment given to the spam it cannot be easily distinguished from - but I will still be able to exercise my right to be whoever I want to be on the internet (just like a spammer), without complaining about the ISPs who choose not to let me send mail using their domain, from any server I feel like. The domain owner, along with the company who hosts email for that domain, are the ones who experience consequences when the domain is used in unauthorized email. Therefore I think the domain owner and/or hosting company has the right to specify authorized servers for specific domains, and exclude all others. (I think the domain owner should be able to override the hosting company settings though.) I don't believe that having an account at AOL.com gives me the right to demand that a class of "legitimate mail" be supported so that I can use my AOL.com return address going thru any SMTP server in the world. AOL provides webmail for those travelling. So do many corporate email systems and ISP email systems of all sizes. Webmail bypasses all "grabs or blocks of port 25" done by hotel chains or the dial/dsl/cable access provider I happen to be using, wherever I am. (And as others have noted, there are port alternatives to 25 for SMTP - we run a port 80 SMTP ;) for our customers to use from any access-ISP.) Yes, I believe that domain owners such as AOL.com should set a policy with their users to only use AOL outbound servers. And I believe that all ISPs have palatable options for dealing with the "account forwarding" issue. ( See ForwardingSolutions ) My definitions and examples of non-malicious forging categories: ------------- Consumer-level consensual forging I configure my email client for a return address of a domain I don't own - such as aol.com. I send through smtp.east.cox.net. I'm not easily distinguishable from a spammer doing the same thing. Solution: My email is rejected and I think "wow - things changed and I can't do that anymore." I change the setting because it no longer works. Like when I make a typo in the return address setting in my email client. People can't write me back. Like when it rains or the price of gas changes. Like when Cox blocked port 25 and I had to change my settings. This is reality - I accept it. Using a return address which is not authorized for the server you send through - becomes a wrong setting. I, like Meng, believe this will come to pass. A few PSA's wouldn't hurt and are entirely within the capabilities of the anti-spam community to generate. ------------- 3rd party consensual forging - not joejob-able: Paypal.com and Ebay.com send email to one of my vendors or customers - with my consent - through their servers - "forging" my return address. They do this when I use a web form on their site indicating my desire to send communication to that vendor or customer. A joejob or spam from this source is not likely, because I had to be double-opt confirmed and signed in with user / pass to get to that form. So long as the recipient server knows (can identify reliably via an anti forgery method) and trusts ebay.com and paypal.com servers, these "consensual forgeries" can be accepted. Or more ideally, paypal and ebay would shift their sending practice just slightly using one of the suggestions at the end of this email. ---------------------------- Joejob-able "consensual" forging: http://www.washingtonpost.com/ has a Tell A Friend type service to send article URLs. Only ... I can pretend to be ANYBODY. And I can add whatever I want to the text - even IMGs and offers to deliver Viagra to your door. An unsophisticated recipient might be fooled by me posing as someone they know. The envelope-from and header from are forged to whatever the "sending-friend" types in. Again it may be trivial in my opinion for the Washington Post and other Tell A Friend type forms to simply use their own domain, identifying the purported sender name / address with a method as mentioned at the end of this email. It just hasn't been policy, there just hasn't been a reason to, until now. --------------- Account redirection or account forwarding forging ( See ForwardingSolutions ) --------------- Malicious forging - too obvious to warrant examples, and yet maybe a reminder of what all legit senders need to be clearly different from - malicious use of a domain in envelope-from or headers of a message sent through other-than-that-domain-outbound servers, for the purpose of hiding my identity, avoiding unwanted traffic, avoiding rate limiting, and/or joejobbing. --------------- We do need to educate consumers as well as outbound email admins and web architects about their responsibility to differentiate themselves from malicious forgers. Why "act like a spammer?" It is not that hard to accomplish the intention of including the supposed sender email address or name, in a greeting card or a Tell a Friend form triggered email. I believe it is even possible to cause most email clients to Reply-to the supposed sender, while the envelope-from, errors-to, and header from remain the domain associated with the sending server for malicious forgery detection purposes. Some ideas: - FROM: "april@aol.com" <CARDS@AMERICANGREETINGS.COM> - FROM: "April Lorenzen" <CARDS@AMERICANGREETINGS.COM> - Include a Reply-to: header of the supposed sender address, and an Errors-to: carderrors@americangreetings.com - Use card@americangreetings.com in the header from and simply put the supposed sender name, and or email address, within the subject or body of the message Having been the recipient of many greeting cards I did want to receive, I can say that universally I clicked on the card URL. There I could see who claimed to send it to me, and nowadays, click to reply to them on the card site through a web form with another card, if I couldn't be troubled to copy and paste their address. - April Lorenzen <HR> expedia.com - people send their itineraries to friends and family from the site and env-from is the personal address but server is expedia.com <HR> From unknown Fri Sep 10 18:29:41 -0400 2004 From: Date: Fri, 10 Sep 2004 18:29:41 -0400 Subject: Why not use "Sender:" and "From:" as intended in RFC 2822? Message-ID: <20040910182941-0400@wiki.outboundindex.net> "Sender:" is clearly defined as the party that caused the email to be sent. "From:" is the author. So if a person customizes a greenting card with own message, that person is the author. To be RFC compliant "americangreetings.com" should put the author's email address in the "From:" header and their own address in the "Sender:" header, and that should be sufficient to tell that it is not a forgery in the way spammers do it. Spanmmers don't include their own email address in a "Sender:" header. Of course there is another legitimate solution for americangreetings.com that would use a "From:" header with the americangreetings.com domain and still it would be the authors address, and that is to create a special email address for each card sent. So if April Lorenzen sends a greeting card and specifies "april@aol.com" as her email address, americangreetings.com might create "fa785aggf875awer@americangreetings.com" as an email address that forwards to "april@aol.com" and use the header From: "April Lorenzen" <fa785aggf875awer@americangreetings.com> in the greeting card sent. This is 100% RFC compliant and is also polite to the user and to the population of the internet. Anoter way might be to create an address like "april#aol.com@americangreetings.com" as a forwarding address. The former is similar to sneakemail.com reverse forwarding and the latter similar to spamgourmet.com reverse forwarding. Anyway, there's no requirement that "From:" would be associated to the sending server. Actually there is a requirement that it would not be associated with the sending server if the author is not a user of that server, and there is also a requirement that in such a case the actual sender be identified using a "Sender:" header. I don't like the word "Forged" being used in most cases you describe as "consensual forging". Putting true information in the "From:" headers as the standards rquire isn't "forging". The standards clearly specify exactly what header should specify the info you want in the "From:" header. Ofer Hadas. outboundindex11sep04.wiki.hadaso@spamgourmet.com From AprilDL Sun Sep 12 23:03:53 -0400 2004 From: AprilDL Date: Sun, 12 Sep 2004 23:03:53 -0400 Subject: Thanks Message-ID: <20040912230353-0400@wiki.outboundindex.net> Thank you, Ofer, for thought provoking observations and suggestions. Perhaps it is not a forgery for ebay to send "Question for Seller" emails with a header From: of prospectivebidder@hisisp.com - the problem is that they do so with an envelope-from of prospectivebidder@hisisp.com. That's what I'm calling a consensual forgery. Thanks for pointing out the proper use of the header From: per RFC 2822. Forgery may be too strong of a word or the wrong word - however according to SPF or most other designated sender schemes, these examples aren't yet discernable from malicious forgeries.
Optional note: