Forums

Unfortunately no one can be told what FluxBB is - you have to see it for yourself.

You are not logged in.

#1 2017-01-30 18:29:16

chris98
Member
From: England, United Kingdom
Registered: 2013-05-31
Posts: 1,292
Website

Additional restrictions or improvements to email form

I've spoken to Franz about a spam email I received from the email form here on the FluxBB website, and we both agree that the current email form is open to a massive amount of abuse.

On my own website, there has been some quite serious abuse sent to members, and because this is an email sent, with only one copy, no administrator or additional team member knows about this email unless it's brought to their attention by the user themselves in question.

The problem as I see it, is that the current system allows users to virtually send anything to a user on the forum, any form of abuse, spam .etc. and it goes completely unchallenged and un-vetted with only one copy ever sent.

I did suggest to log emails, but Franz rightly pointed out that this could cause issues with data protection laws in various countries.

It was also suggested that a mod could be made to log emails, which I'm quite happy to make myself at some point. But, it would be interesting to see what other ideas people could come up with to try and prevent this form from being abused in the future.

After all, it probably is only a matter of time before some serious issue is discovered on a forum somewhere through sending these emails out. And the hosting account owner would be held responsible, so it could get quite messy.

This is more of a discussion topic to see if we can think of anything as a community.

Offline

#2 2017-02-08 00:32:24

eric235u
Member
From: free software land
Registered: 2008-05-10
Posts: 132
Website

Re: Additional restrictions or improvements to email form

Captcha on the form.  An easy way for users to report abuse.  Can't stop a dedicated human spammer but you can slow them down significantly to where they should go away.  Ban user names, emails, and IP's.  Should be enough no?

Offline

#3 2017-02-08 10:51:35

chris98
Member
From: England, United Kingdom
Registered: 2013-05-31
Posts: 1,292
Website

Re: Additional restrictions or improvements to email form

That is a very good idea. Definitely something which should be considered.

I'll think about making a reCAPTCHA plugin for the forum.

Offline

#4 2017-02-09 09:34:07

tuia
Member
From: Lisbon
Registered: 2014-09-18
Posts: 17

Re: Additional restrictions or improvements to email form

Drop the email messaging and make it to the core a mod with forum private messages. I am baffled by FluxBB still using email messaging between users.

Last edited by tuia (2017-02-09 09:39:54)

Offline

#5 2017-02-10 08:53:28

Franz
Lead developer
From: Germany
Registered: 2008-05-13
Posts: 6,664
Website

Re: Additional restrictions or improvements to email form

@chris98: I've already created one.


fluxbb.de | develoPHP

"As code is more often read than written it's really important to write clean code."

Offline

#6 2019-09-10 13:23:03

JJones
Member
Registered: 2019-04-28
Posts: 59

Re: Additional restrictions or improvements to email form

The Problem with the entire system is that the core treats sending emails the same way most forums are used to send Private Messages ... the "reCapcha" does not solve bad systems, it simply adds a level of protection from bots or auto processing.

The REAL solution would be to drop sending emails through your host from your site, and to the end user ( You are liable for all data being sent from your host )... This basically means to convert the email system to use a PM system, and just use the email as a mailto anchor tag. The system should NEVER process a REAL email from one user to another ( why does fluBB need a copy of an email that some random user sends to me? )

Either use a PM system or convert the email function to mailto anchor tags, or BOTH  ( Ethical, Simplistic, Issue Solved, and Resource Friendly ).

Offline

#7 2019-09-10 14:19:36

GWR
Member
From: Germany
Registered: 2010-08-06
Posts: 209

Re: Additional restrictions or improvements to email form

Forum emails:
This is the communication form "userA -> forum -> userB" without requiring userB visiting a forum regularily.
It also allows communication between both without sharing the email address.

Of course the forum mail system should hide the sender's mail address and also allow to set mailing to private / just buddies / just admins / ... or even more fine grained.


bye
Ron

Offline

#8 2019-09-10 15:09:36

JJones
Member
Registered: 2019-04-28
Posts: 59

Re: Additional restrictions or improvements to email form

I'm well aware of how the system works ... I am one of many that completely dumped the outdated email system, and exchanged it with a tiny PM System ...

User A is hidden from User B ... User B is hidden from User A .... but the System sees both users, their data, AND the communication. The difference is that the HOST now "sees" ( 1 line of code and the webmaster can log any email communication they want ) your "Emails" instead of a PM. All while "Implying" the email is "private", which it never was since the SENDER is the Host! ( LOL, and people want to know how NSA can so easily access your communications ).

Worse, as you said, removes the need to visit the host .... in that case, why even use a forum system? The entire point of a website is to generate traffic ( if people are not visiting your site REGULARLY ) your popularity tanks, and your Domain Depreciates in value, not to mention that even internet bots lose interest in your website. ( Great Thinking! )

Offline

#9 2019-09-10 20:38:08

GWR
Member
From: Germany
Registered: 2010-08-06
Posts: 209

Re: Additional restrictions or improvements to email form

I host a forum so people could ask questions about my software. Next to the forum they could use github, facebook or other media on which I am listening to their wishes and bug reports.

If I received an EMail by someone then this might be because the forum does not contain an PM-system (or the PM-System notified the message via EMail ...). I received it because someone wanted to write me something he would not write into a public thread. Think we all knew that already.
So why using an EMail system rather than a PM system? Host load. FluxBB tries to be lightweight (as you know there is still a lot to optimize). Adding a PM system adds to the DB, adds more layers of software to maintain and of course adds traffic (on an ad-free website this just means some euro cents of cost per year - nothing to worry). FluxBB tries to skip as much "bonus features" as possible - one of these was the PM system.
Think this is the main reason for having the email thing.

In a PM-system the host can read the messages too - except the messages were encrypted on client side already. So as long as the message gets "plain text" transported from userA to server and then to userB it can get read. It can get read by the server, the users and uhmmm "agencies".


Nonetheless the email system (or the PM system) could be misused to write to someone who blacklisted your mail address or marked it for spam - as the real sender is the forum host - which you most probably did not blacklist as it could send you regular mails.


bye
Ron

Offline

#10 2019-09-11 05:01:32

JJones
Member
Registered: 2019-04-28
Posts: 59

Re: Additional restrictions or improvements to email form

Host Load? You do realize that an EMAIL requires more "load" than sql data storage? The entire point of MySQL was to serve millions of records in a matter of a few hundred milliseconds. In fact, EMAILS are so problematic for Hosts that ALL hosts have limits on batch sending emails. Who told you email serving is "low load"?

If managing SQL Tables is problematic, troublesome or complex, than you are clearly doing something wrong with your databases. No amount of "layers" ( maybe after a few thousand? ) is going to reach the "load" levels of string storage compared to email processing.

I'm nearly sure that at some point FluxBB Developers ( probably in the past ) believed that lower number of sql tables equated to "fast" or "efficient" services ( probably a marketing idea ), yet their claims were simplistically false.

This is completely TRUE about a PM system, however NOBODY ( unless they are naive ) believe that a "Private Message System" is actually "private", however People DO hold an expectation that their Emails are Private. Staff Members are expected to deal with user harassment on their own services, FluxBB simply skipped that step claiming the reason to be "lightning fast" which it clearly is not faster than half of the other forum scripts.

If User A is "abusing" ( you define that word however you want ) User B .... that is not a "software" problem, that is a "social" problem, which is why you have staff members in a community. No Amount of Software will ever "fix Asshats" ... Facebook ( MySpace prior to that )  taught us that, and worse showed us that Software actually just creates more efficient asshats.

However, from a legal standpoint, FluxBB decided to push its laziness onto the host. Lets take a hypothetical situation and apply it to legal standards in any common law origin nation ( judging by the recommended host providers page ( 95% being US businesses )) .... Lets say i use the email function on this forum to send a nude photo of a child. Because the Email is being sent from the host of this forum, they become criminally liable because the host is actually the original sender ( see the email headers ) of the email. Take that a step forward, and have the email reported to an authority agency, and it will most likely result with the Host removing the website from its service.

Basically, the HOST is ALWAYS liable for the content it serves. FluxBB simply provided a way for a malicious person to legally take a Forum offline using an illegal action. ( this is primarily the reason i removed the email-to-user function from my core edit )

Offline

#11 2019-09-11 05:48:40

Franz
Lead developer
From: Germany
Registered: 2008-05-13
Posts: 6,664
Website

Re: Additional restrictions or improvements to email form

JJones wrote:

I'm nearly sure that at some point FluxBB Developers ( probably in the past ) believed that lower number of sql tables equated to "fast" or "efficient" services ( probably a marketing idea ), yet their claims were simplistically false.

Please stop spreading FUD.

The email system was devised to be the most simple solution to get a private conversation started. It isn't perfect, as you mentioned, but it works well for many people.

Regarding privacy: The emails being sent are not read / stored by the host by default, the private message system always does it - it has to to be able to work. So that seems to be a very weak argument. wink


fluxbb.de | develoPHP

"As code is more often read than written it's really important to write clean code."

Offline

#12 2019-09-11 21:19:02

GWR
Member
From: Germany
Registered: 2010-08-06
Posts: 209

Re: Additional restrictions or improvements to email form

Regarding host load:
So after a user wrote me a personal message it just needs some SQL queries to reach my screen?
User writes a PM:
- server request
- db connection established (eg. mysql)
- db table queried ("can I send?")
- db table queried ("I want to send X")
- db connection closed
- results printed to user (via an ajax-json reply?)

Now it requires the other user to log in:
- ohhh new message available
- clicking on "pm system page"
- db connection established
- db query ("whats up?")
- site generation (or ajax response to auto fill a previously fetched static page + static assets from cache)
- content reached and displayed

This does not create load?

Now send the email (initial page creation similar to PM system):
- click on send
- postfix and dovecoat called to arms (waiting on a socket already)
- mail send out ... fire and forget style
- mail bounced? ok
- opposite mail server wants a graylist validation? check ... reply and send again

user receives it:
- no matter what they do there now, it does not create load on your server


Yes, batch sending mails is expensive and requires a some load but similar to optimizing your MySQL et. al you can optimize your mailer daemons.
The only reason for a PM to scale better is that a socket is "expensive" while an open DB connection (persistent connection) only requires a bit more RAM. So if you think you are sending 1000 PMs per second then yes, a PM system will work better - but if your users are sending 1000 PMs a day then the mail server might be easier to maintain than a PM system (which is "frontend" and so prune to get hacked somehow).


Regarding abuse/illegal content:
You cannot attach an image or other file to your mail. It is plain text. In most PM-systems you could add - or at least "bbcode"-ify your messages and so straight insert the  image of a "naked snail licking an ice cone" to make the userB barf a round or two.

PM systems can get "cleaned up": users delete messages. If you decide to only "hide" (for legal "archive"/proof reasons) then you run into the problem of potentially having illegal content in your database ... no problem as long as you are not aware of it, and as long as nobody leaks the raw data of your DB.

The Email-System can always log part-anonymously (senders IP when posting the mail - same as you would do for a PM). An EMail can auto-junked based on your junk filters ("naked" + "snail" + "licking"). Dunno if your PM provides junk filters, autocategorization, relaying, forwarding, ... too.

If you added "notify me on new personal messages" then you might even get the content to your mail address now too (with the hosts sender address and IP). Same problem than "email".

PM Systems can more easily be breaken in than into your local mail client or online mail box (as you can update your mailbox software on your server, your mail client on your computer - but the forum software of the fansite you are visiting must not be up to date - it is 3rd party hosted).

EMails are "90s" but still versatile (remember github: new commit, reply per mail and you added a comment, reply to comment-notifications to reply to them ... and so on). So you can more easily incorporate stuff if you had a proper access to your server (so access to the mailer daemon and so on).
But this is something a "vanilla board" might better not require as else many people will skip hosting it because of too many steps to climb.


But yes, raw EMail is not the most perfect solution - but a PM is no 100% perfect replacement for it.


bye
Ron

Offline

#13 2019-09-12 09:25:40

JJones
Member
Registered: 2019-04-28
Posts: 59

Re: Additional restrictions or improvements to email form

I notice you did not post the breakdown of the php mail( function but attempted to do so with the SQL query functions? You should honestly do some load balance testing on some of the popular HOSTs you can think of. I am actually willing to bet that you don't know how for the following reasons:

1) You claim that a single sql query process requires MORE resources than a single Email. Just for Reference: EMAIL SERVERS are by nature horribly resource intensive, which is why HOSTs set CAPS to protect their boxes.
Hostgator "claims" 5,000 emails .... LOL, i BET if you try to exceed 150 in their measured hour-period you'll find that they have a que system. (PS: I did a lot of work for HostGator and absolutely LOVE their dishonesty )

2) sql queries were ALWAYS less resource usage than ANY other type of data serving ( Bench-mark test for yourself! ) and even more important is that they get FASTER and less Resource Dependent each update (lol, did you even bother to look at PDO? )

... Quoting GitHub .... I am assuming you are unaware of GitHub Wars with other repos ... GitHub was notoriously known for some very unethical "theft". which is why i refuse to hold a github account ( as i have already stated in my post about my edits, which is why there is no "shared" url for download through a git repo.

You have 0 Ability to update a Mail Server ( outside of a dedicated server). You speak as if you actually believe that a "client" holds authority over a box from a host. Do you believe that if you lease/rent a home that you have the ability to change the roof, windows or knock out a few walls too?

If the only choices are PM / EMAIL communication, then YES PM Systems are by far the 100% solution to the issue on the grounds of "1) Legal Liability,  2) Resource Usage of the Host, 3) Moderation for Social Problems in a community". phpBB(2 & 3), PressBB( wordpress forums ), SMF, IPB, blah blah blah ... have all been through this same debate, and they ALL have the same conclusion ( PM > Email ) and for a lot more MAJOR reasons than i have claimed.

@Franz .... using the code term of "simplicity" as a cause for specific development choices is often seen as a form of laziness. However, if you go back and read my reply, it specifically states the "expectation of privacy" between the two systems. NOBODY expects Emails to be viewed by anyone .... NOBODY expects PRIVACY on a website that requires internal communications ( PM Systems )... Try and READ what was stated before you begin claiming FUD!

Unless you honestly believe that people DO expect emails to be "public", but that would fly in the face of every data breach in  the media from the last 10 years.

As far as how "simple" it is to record these emails.... its ONE LINE OF CODE:

error_log("Whatever Email Text that the user posted", 3, "/path/my-logged-emails.log");

Parsing the first option to include the sender / receiver data is easy enough since you are already passing that information to the mail function...

Who is to say what YOU or logging and what other webmasters are logging, deny or admit, what determines who is a trustworthy person or not?

Offline

#14 2019-09-12 20:40:04

GWR
Member
From: Germany
Registered: 2010-08-06
Posts: 209

Re: Additional restrictions or improvements to email form

Of course I can log mails on my server ... the same way as I can log PMs send over my services (except for a client based end-2-end encryption).

And of course I can configure the mailserver on my dedicated server (even if it was only a virtual machine). Limitations are hardware limitations - and maybe some TOS of the provider connecting your machine to the "internet".
So I am pretty sure to be able to send more than some hundred of mails per hour. I know that the communication between the server and the remote server is ressource hogging. But once you've sent the mail in most cases "your job is done". It is up to the other mail server + the mail client of userB make the mail available to this user's eyes.

A PM System requires both users to access the website (must be online then), means you have 2 times to fulfill the request to load some data, send out page code, read cookies ... and all this stuff.
SQL queries are of course kind of fast - if they are not under full load already because of some hundred parallel page requests (would happen to mail servers too - if you push them with some scripts but page requests are "normal" and happen without some faulty attacks).
So if you have multiple web services on your host (forum, website, ...) then SQL will already be under a bit of load. Somewhen you might reach a limit of concurrent access, so you need to update your config, extend RAM, ... to not run into a non-reachable-DB. Persistent connections are then kind of an enemy to you.

As you use caches you will skip a lot of DB load there - except it has to refresh stuff in that moment, then you get stacked loads which takes some time to "calm down".


But regardless of what is using more CPU, memory, takes more time or less users:
- providing a simple email form is done in a short time, it can be secured in a short time and the handful of LOCs allows for an easier maintenance if required
- providing a PM allows for more flexible interaction ("chats", multi-user-messaging", bbcode, history without polluting once mailbox, stuff stays "on this page" - might be more secure than your mailbox ;-))
- providing a PM requires more code to be written, to be maintained, ...

Also PM-Systems somewhere need to inform the users, lookups need to be done ("Any new PM for this user?"), yes you can cache this information again on "happening" (PM is sent? invalidate user's PM info cache) but you might get the point already: on each request the user does to the website the PM info has to be "handled" (created and/or displayed). EMails are a one-shot thing (sent and done). So as long as emails are not send by all simultaneously it will create less load and/or traffic than a PM system.

Nonetheless I can understand that PM systems exist, are in use and favored by many people - yet FluxBB claims to be lightweight and skip as much "convenience extras" as possible.
If you worked in a bigger team or have a lot of spare time (or get paid) then features are a different thing.


bye
Ron

Offline

#15 2019-09-12 22:10:22

JJones
Member
Registered: 2019-04-28
Posts: 59

Re: Additional restrictions or improvements to email form

IF you "OWN" a dedicated box ... WHY ON EARTH are you wasting your time on OpenSource Scripts? You would be so much better off using https://www.vbulletin.com/ as a platform than Flux or any variation of these script kiddies. In fact, a lot more money to be made writing scripts on their market place since the platform is licensed and encrypted ( thus you are protected )....

Are you by any chance Using Cpanel? If so, which version?

As for Time & Money ... I have been writing Server Side Systems since age 19 .... I am nearly 40 now with multiple companies ( one of which is Tech ( not to be confused with IT ). Our Clients are Government Contracts not public. At one time in my life, I used to live to code ... now it is nothing more than a passive hobby, and i only get involved with projects I hold an interest in ( Like this damn Vietnam Expat Community ).

PM systems have dominated CMS systems since before my lifetime ( and for the reasons i have already stated ) .... Flux is free to decide whatever features it wants in its outdated core ( which is clearly why this community is so slack in activity ) ... And I am also free to Strip it down and do as I wish ( My interest in FluxBB was simply because of its lack of frameworks ... Native Functions are always faster and smoother, not to mention a hell of a lot faster to strip down and rebuild.

If you get bored enough and want to test the "legal" liability ... find a site operating FluxBB with the default email contact system, and use it to send some nude photos to one of your own ALT accounts .... Then report those emails to the ISP of their Host .... Just sit back and watch the drama unfold as that website disappears off the internet. ( at the very least for a few weeks ). No amount of "code" will ever fix that issue.

PS: What in hell is the obsession with BBCode?

Offline

#16 2019-09-16 20:14:44

GWR
Member
From: Germany
Registered: 2010-08-06
Posts: 209

Re: Additional restrictions or improvements to email form

Albeit you might not read it "officially" anymore because of your "ban":

- I "own" (or "maintain"/"administer") a dedicated box. I do not use cpanel or other administrative helpers, doing that by hand is fast enough and I do not really trust these manager panels (froxxler, cpanel, ...).

I started coding webstuff somewhere in the late 90s (Perl / SSI) and moved on to PHP some few years later. Almost stopped web dev in the early 10's of this century - did not really like this namespace and framework thing they started to add to all the tools.

I prefer to use FOSS software - the same way as I publish a lot of my code (games, framework stuff) as FOSS too.
I am using FluxBB as it is lightweight and an ancestor of punbb which I was using after switching from invision power board - which went too commercial that time.

When I started web development I already avoided PM systems if I saw them.


@ legal
I was in contact with the police in connection to my fluxbb installation - but they wanted to know if I knew the current IP of someone who never posted in our forum and registered an account many years before - he was accused to have done some stuff to children.
My website in no way disappeared from the internet.

With todays technology I wonder if they are even allowed to check what mails are sent from your server - and which not. Else it would be easy to fake some mails (if you skip the security options to avoid such fraudulent behaviour) and then tell the "sender's host" that they've send you bad bad stuff.
If they _really_ put the website down then they are sueable (for regress) by the original site owner. Most of the time they tell you this: go to the police, tell it to them - and then the police has to come to us so we can do something.

Had a similar thing when someone copied my website under a different tld (samename.othertld) and placed a lot of hardcore porn advertisement on it. I reported to the police (identity fraud - as he used my name in the impress) and they did ... nothing.
Hoster did temporary disable that website as I was able to proof (id card and so on) to be the person named in the impress - and that I did not want to have this page there. The one who uploaded (some Eastern European one ... with a German "fellow" for the bank account to earn money of German advertisement services) seems to have lost interest in even trying to reactivate - this only because I assume it was an automated "clone" process.

Yet they did bad stuff and it was not too easy to blame them for doing stuff - I had to proof that this was not me.


@ bbcode
This is what the forum here (and other forums) support.


bye
Ron

Offline

#17 2019-09-18 12:45:23

JJones
Member
Registered: 2019-04-28
Posts: 59

Re: Additional restrictions or improvements to email form

1) I've never heard of "FOSS" .... but I am a very big fan of Cpanel ( I just hate their license fees ).

2) Legality ... Its not really illegal to "duplicate" a website and just pop it up on another domain. Some call it "phishing", some call it "click baiting".... It's not really "Illegal", unless images or content being duplicated is copyright ( rarely ever is ).

As for a HOST or a Gov having legal authority to read Email .... It is very legal. EU duplicated the US in terms of records. Anything that passes through an ISP ( including a host server ) is required to maintain records of each data transaction. US Legally requires hosts to maintain records for 6 months to 2 years... EU has a similar law ( i am just not familiar with the length of time required to maintain those records )...

Simply put, YES they can petition you to relinquish those records at any time. Depending on the level of the Host, they might not even make a request, and walk right in and take them. This was the entire point of email encryption as a solution, but commercial grade encryption just isn't all that great. ( There really is no solution to GOV oversight... if they want it, they can always get it. The only question is how easy is it for them to obtain the information ).

ALSO: After digging around about "IDs"... I just found a way to pass a single POST_ID through $_GET or $_POST without the need of it being linked to FORUM_ID or CAT_ID ..... I am still in the process of bench-marking it since there seems to be at least 8 ways of doing it. I think i just changed my goal to eliminate a loop for viewing FORUMS without having to loop through them. ( Your question actually triggered me to look into the possibility and i found the process to be even faster! ( thanks for that )).

Offline

#18 Yesterday 18:00:40

GWR
Member
From: Germany
Registered: 2010-08-06
Posts: 209

Re: Additional restrictions or improvements to email form

FOSS - free open source software


2) legality
Every graphic beyond a a rectangle or line can be automatically copyrighted in Germany - there is no "copyright" but a socalled "Urheberrecht". Stuff I did there are graphics I did (not just logo - but complete game background, HUD, ..).
Same for texts: I wrote texts - and articles. I am the owner of this and nobody is allowed to duplicate that without my allowance.

Also the persons did a so called impersonation by copy pasting my impress (with name, address, phone ... as required by German law for such websites).

I accept that people "copycat" websites (make them very similar looking, similar articles ...). Regarding "phishing" - it's not that the activity (fraud) nor the cloning of websites is legal. At least in Western Europe (or maybe even the EU at all) it is not legal.



@ data transaction
But not the data itself - receipient and sender of packages might be protocolled yes.
The data might be encrypted so why store it (except it is from/to a "monitored" IP/user).

If you do not process user data (which "sending mails the user wrote" might not include) then you even are not allowed to store the full IP of users doing stuff on your server. Only the ones who process data will have to store extra stuff. That's Germany ... where people have to anonymize IP addresses so no user tracking is possible etc.



@ thanks for that
No problem wink


bye
Ron

Offline

Board footer

Powered by FluxBB