View Full Version : Problems posting pmails with latest Opera browsers? Read this.
07-26-2008, 01:52 PM
I finally (it's taken a while, although I've not been actively trying to "debug" the issue) figured it out:
You HAVE to enable "Send Referrer Information". Press F12 or go to the QuickPrefs and look for it.
Normally I turn it off since many times it's abused and a security issue, but for Amiga.org you must turn it on for pmail to work. Sucks and I don't know why, but that's the deal I guess.
BTW, when it doesn't work the pmail window says:
... yet it never sends the pmails.
DING DING DING DING!
I just realized: the referrer info sending is what's also keeping Opera from posting or editing posts! (just had it happen to me!)
Thank you very much for sharing that information. I'm sure it'll be quite useful to other Opera users.
07-26-2008, 02:18 PM
Referrer information is often used as part of validation by web sites, in addition to cookie or session variables. It does a small part towards preventing posting abuses, session hijacks, and the like.
07-26-2008, 02:34 PM
I don't know all there is about this topic (and would like to know more), but what I do know is that it's actually used maliciously by many sites and hackers because it's flawed by design or rather aspects of it. See links at the bottom of the following:
and of course this:
A question that always came to my mind is:
Why many sites (most of he ones I visit) don't have a problem with it off? (in the sense that if it's very good for security...) I'd be interested to learn more about the why in this case.
07-26-2008, 05:04 PM
To be fair, so does SMTP, DNS (one which just became a major annoyance,) POP3, FTP, and other protocols. The difference is that some ways of doing things are improved upon.
For instance, using the referrer is only part of determining a valid session. There are better ways of doing so now.
In particular error, the very old formmail.pl used the referrer header to determine if the POST or GET (should be a POST method) came from a valid page. Valid pages were stored in an array and compared against the referrer -- you get a match, the message is passed. This became a problematic method because the referrer header was easily forged, and requests could be sent directly to the script without first visiting the form page. Additionally, several internal variables were carried by hidden values which could be overridden.
I wrote a formmail.php script a long time ago which uses a one-time token stored in a cookie variable. Valid tokens were stored in a local table contained within an mm (shared memory) container, local text file, or a database using a flat-file (*dbm) or MySQL back-end. This helped ensure that the form page would be visited first to obtain a token, then a POST method sent to the PHP script which then also used IP address and time discrimination.
Of course, that became a problem as well because it would have been easy to have an automated attack collect several tokens and then use them to send messages. This was mitigated by a few randomization and hashing tricks, as well as not passing any special variables hidden within the form. Even so, there are still ways around this protection.
Bah. Anyway, I guess my point is that this version of the forum software may rely upon the referrer, but modern versions may not. Wayne mentioned a while back that he has stuck with this particular version because it is Amiga friendly. And as such, we're trapped within its limitations.
There's a referrer management plug-in for Firefox (2.x and below) which offered a white-list for sites to which you wanted the referrer sent. If that's an option in Opera 9.5 (I haven't bothered to look, yet,) then that might be a feasible option.
The referrer header is a useful tool for tracking statistics, like referring websites and the like, so long as the referrer string is "sanitized" by the browser: removing GET request parameters, only sending a referrer when following a link, and various other methods. Though removing query information can cripple the ability to track search queries used from search engines, and so on. (Pay special attention to the RFC you referenced above.) And you'll see in at least one of the links you provided that referral security is also open to implementation flaws.
Eh. Security first.
vBulletin® v3.8.4, Copyright ©2000-2013, Jelsoft Enterprises Ltd.