Topic: RuggedInbox.com - Free offshore email - page 9. (Read 45077 times)
You guys gotta fix your typography on main page. The Bold has made lettering blurry. On my res anyways.
Is it possible to enable DANE for ruggedinbox?
Hi!
But you keep logs, that this sentence is a lie:"This service does not and don't need to comply with such regulation: we don't have such logs." It's put away this sentence from the main page
But you keep logs, that this sentence is a lie:"This service does not and don't need to comply with such regulation: we don't have such logs." It's put away this sentence from the main page
Hi kubussz, the confusion is given by the fact that we are talking about two different logs:
1. system logs: those are linux logs, for example syslog and dmesg, the web server and the other services logs. In short, the system logs.
We have those logs and the rotation policy is 1 week.
2. data retention: the statement that you quote from ruggedinbox's features page ( http://s4bysmmsnraf7eut.onion/features.php ) is from the paragraph "NO Data Retention".
"Data Retention" are special logs: https://en.wikipedia.org/wiki/Telecommunications_data_retention
which save metadata: sender, recipient, sender ip address, timestamp
and we don't have such logs.
Let us know if you need more information.
Thanks for your interest,
RuggedInbox team
Thank you for your response.
I have a question!
"This service does not and don't need to comply with such regulation: we don't have such logs."
AND...
"ALSO .. we changed the log rotation policy.
Before it was the Debian default: 1 month.
1 month is too much, we don't need it and privacy-wise, the less the better.
The new policy is 1 week: system logs and web access logs are kept for 1 week.
(this can still be improved, in the near future it will be 48 hours)"
which statement is true?
I have a question!
"This service does not and don't need to comply with such regulation: we don't have such logs."
AND...
"ALSO .. we changed the log rotation policy.
Before it was the Debian default: 1 month.
1 month is too much, we don't need it and privacy-wise, the less the better.
The new policy is 1 week: system logs and web access logs are kept for 1 week.
(this can still be improved, in the near future it will be 48 hours)"
which statement is true?
Hi,
The policy is 1 week: system logs and web access logs are kept for 1 week.
This is the current configuration.
Feedback is welcome also on this topic.
Hi!
But you keep logs, that this sentence is a lie:"This service does not and don't need to comply with such regulation: we don't have such logs." It's put away this sentence from the main page
Thank you for your response.
I have a question!
"This service does not and don't need to comply with such regulation: we don't have such logs."
AND...
"ALSO .. we changed the log rotation policy.
Before it was the Debian default: 1 month.
1 month is too much, we don't need it and privacy-wise, the less the better.
The new policy is 1 week: system logs and web access logs are kept for 1 week.
(this can still be improved, in the near future it will be 48 hours)"
which statement is true?
I have a question!
"This service does not and don't need to comply with such regulation: we don't have such logs."
AND...
"ALSO .. we changed the log rotation policy.
Before it was the Debian default: 1 month.
1 month is too much, we don't need it and privacy-wise, the less the better.
The new policy is 1 week: system logs and web access logs are kept for 1 week.
(this can still be improved, in the near future it will be 48 hours)"
which statement is true?
Hi,
The policy is 1 week: system logs and web access logs are kept for 1 week.
This is the current configuration.
Feedback is welcome also on this topic.
Thank you for your response.
I have a question!
"This service does not and don't need to comply with such regulation: we don't have such logs."
AND...
"ALSO .. we changed the log rotation policy.
Before it was the Debian default: 1 month.
1 month is too much, we don't need it and privacy-wise, the less the better.
The new policy is 1 week: system logs and web access logs are kept for 1 week.
(this can still be improved, in the near future it will be 48 hours)"
which statement is true?
I have a question!
"This service does not and don't need to comply with such regulation: we don't have such logs."
AND...
"ALSO .. we changed the log rotation policy.
Before it was the Debian default: 1 month.
1 month is too much, we don't need it and privacy-wise, the less the better.
The new policy is 1 week: system logs and web access logs are kept for 1 week.
(this can still be improved, in the near future it will be 48 hours)"
which statement is true?
Hi!
server s4bysmmsnraf7eut.onion Stopped Working?
server s4bysmmsnraf7eut.onion Stopped Working?
Hi kubussz, http://s4bysmmsnraf7eut.onion is proudly up
however we noticed that from yesterday, sometimes we need to click "New Identity" on our favorite green onion button
to rebuild a Tor circuit, because of timeouts.
On our server, services are up, traffic is coming thru the hidden service and we are not getting DDOSed
so perhaps it is a temporary issue with the Tor network in general.
On the tor-talk mailing list, everything looks ok: https://lists.torproject.org/pipermail/tor-talk/2014-October/thread.html
Thanks for the feedback!
RuggedInbox team
Hi!
server s4bysmmsnraf7eut.onion Stopped Working?
server s4bysmmsnraf7eut.onion Stopped Working?
Thanks for creating such a great service!
But unfortunately it seems that the mail servers are currently down. No matter if I try to connect via Squirrelmail or RoundCube or POP3, there's always a timeout when fetching the mail contents.
Any idea?
Any alternative to ruggedinbox.com?
Thanks
But unfortunately it seems that the mail servers are currently down. No matter if I try to connect via Squirrelmail or RoundCube or POP3, there's always a timeout when fetching the mail contents.
Any idea?
Any alternative to ruggedinbox.com?
Thanks
Hi andyamiles, from the 13th of August we use a third-party monitoring service to monitor our server availability (ping)
and https service (the webmail).
It reports that our uptime is 99.98% for ping
and 99.8% for https
The last downtime was on the 11-09-2014 (11th of September) at 14:49:03
and the duration was 8 minutes (probably some network interruption or routing problem between our data center and the monitoring service one).
Anyway thanks for your interest and the feedback!
Looks good i'm gona try it now. Cheers.
awsome service 
Thanks for creating such a great service!
But unfortunately it seems that the mail servers are currently down. No matter if I try to connect via Squirrelmail or RoundCube or POP3, there's always a timeout when fetching the mail contents.
Any idea?
Any alternative to ruggedinbox.com?
Thanks
But unfortunately it seems that the mail servers are currently down. No matter if I try to connect via Squirrelmail or RoundCube or POP3, there's always a timeout when fetching the mail contents.
Any idea?
Any alternative to ruggedinbox.com?
Thanks
Hi, we have raised the amount of space on all the mailboxes, present and future, from 50MB to 200 MB.
As usual, feedback is welcome.
As usual, feedback is welcome.
It's been working like a charm !!!
Thanks for your assistance.
Thanks for your assistance.
Ok so .. problem partially fixed.
It was an iptables issue: to allow sending emails to the onionland, some iptables magic is needed.
One rule was causing some connections to be dropped.
Now you should be able to hammer your POP mailboxes with claws-mail and see no timeouts or interruptions.
We'll seek some wisdom on the Tor mailing list to check iptables ..
Thanks again for the patience and feedback!!
It was an iptables issue: to allow sending emails to the onionland, some iptables magic is needed.
One rule was causing some connections to be dropped.
Now you should be able to hammer your POP mailboxes with claws-mail and see no timeouts or interruptions.
We'll seek some wisdom on the Tor mailing list to check iptables ..
Thanks again for the patience and feedback!!
Thanks for the assistance. I've made the suggested changes and got the same issue.
* Account '[email protected]': Connecting to POP3 server: ruggedinbox.com:995...
[11:20:32] POP3< +OK Welcome to ruggedinbox.com
[11:20:32] POP3> USER [email protected]
[11:20:32] POP3< +OK
[11:20:32] POP3> PASS ********
[11:20:32] POP3< +OK Logged in.
[11:20:32] POP3> STAT
[11:20:32] POP3< +OK 1 1963
[11:20:32] POP3> UIDL
[11:20:32] POP3< +OK
[11:20:32] POP3> LIST
[11:20:33] POP3< +OK 1 messages:
[11:20:33] POP3> QUIT
** Session timed out. You may be able to recover by increasing the timeout value in Preferences/Other/Miscellaneous.
I've increased timeout out to 180 to no avail. This does not happen every time, however, it does occur about every second attempt. Typically the first time I check the accounts they function correctly and download any messages. If I attempt again it will fail on at least one of the two accounts.
SMTP appears to function within the spec'd 3 minute window with no problem on both accounts.
TKS for all the help.
* Account '[email protected]': Connecting to POP3 server: ruggedinbox.com:995...
[11:20:32] POP3< +OK Welcome to ruggedinbox.com
[11:20:32] POP3> USER [email protected]
[11:20:32] POP3< +OK
[11:20:32] POP3> PASS ********
[11:20:32] POP3< +OK Logged in.
[11:20:32] POP3> STAT
[11:20:32] POP3< +OK 1 1963
[11:20:32] POP3> UIDL
[11:20:32] POP3< +OK
[11:20:32] POP3> LIST
[11:20:33] POP3< +OK 1 messages:
[11:20:33] POP3> QUIT
** Session timed out. You may be able to recover by increasing the timeout value in Preferences/Other/Miscellaneous.
I've increased timeout out to 180 to no avail. This does not happen every time, however, it does occur about every second attempt. Typically the first time I check the accounts they function correctly and download any messages. If I attempt again it will fail on at least one of the two accounts.
SMTP appears to function within the spec'd 3 minute window with no problem on both accounts.
TKS for all the help.
Hi chromedome, issue confirmed (we are able to replicate the problem).
Thanks for spotting that out!
Debug in progress ..
Thanks for the assistance. I've made the suggested changes and got the same issue.
* Account '[email protected]': Connecting to POP3 server: ruggedinbox.com:995...
[11:20:32] POP3< +OK Welcome to ruggedinbox.com
[11:20:32] POP3> USER [email protected]
[11:20:32] POP3< +OK
[11:20:32] POP3> PASS ********
[11:20:32] POP3< +OK Logged in.
[11:20:32] POP3> STAT
[11:20:32] POP3< +OK 1 1963
[11:20:32] POP3> UIDL
[11:20:32] POP3< +OK
[11:20:32] POP3> LIST
[11:20:33] POP3< +OK 1 messages:
[11:20:33] POP3> QUIT
** Session timed out. You may be able to recover by increasing the timeout value in Preferences/Other/Miscellaneous.
I've increased timeout out to 180 to no avail. This does not happen every time, however, it does occur about every second attempt. Typically the first time I check the accounts they function correctly and download any messages. If I attempt again it will fail on at least one of the two accounts.
SMTP appears to function within the spec'd 3 minute window with no problem on both accounts.
TKS for all the help.
* Account '[email protected]': Connecting to POP3 server: ruggedinbox.com:995...
[11:20:32] POP3< +OK Welcome to ruggedinbox.com
[11:20:32] POP3> USER [email protected]
[11:20:32] POP3< +OK
[11:20:32] POP3> PASS ********
[11:20:32] POP3< +OK Logged in.
[11:20:32] POP3> STAT
[11:20:32] POP3< +OK 1 1963
[11:20:32] POP3> UIDL
[11:20:32] POP3< +OK
[11:20:32] POP3> LIST
[11:20:33] POP3< +OK 1 messages:
[11:20:33] POP3> QUIT
** Session timed out. You may be able to recover by increasing the timeout value in Preferences/Other/Miscellaneous.
I've increased timeout out to 180 to no avail. This does not happen every time, however, it does occur about every second attempt. Typically the first time I check the accounts they function correctly and download any messages. If I attempt again it will fail on at least one of the two accounts.
SMTP appears to function within the spec'd 3 minute window with no problem on both accounts.
TKS for all the help.
Thank you for the response. It's occurring on two separate RIB accounts, both configured the same. I'm using Claws Mail via my ISP using SSL on port 995 and 465. SMTP authentication is enabled. The only plugin enabled is GPG. What else can I provide to assist you?
The other account checked via Claws Mail (BM) functions correctly.
TKS
The other account checked via Claws Mail (BM) functions correctly.
TKS
Hi chromedome thanks for the follow up.
In claws-mail, please go to the account preferences -> SSL
and check 'Use SSL for POP3 connection' under POP3
then check 'Use STARTTLS command to start SSL session' under 'Send (SMTP)'
and then at the bottom, check 'Use non-blocking SSL'.
Then go to Advanced and uncheck everything (SMTP port, POP3 port, Domain name, ...) (thus leaving everything as default).
Please let us know if the problems still happens, if so, we'll do a serious debugging,
because honestly, we never did even a single access to RIB directly (without using Tor or torsocks)
Thank you for the response. It's occurring on two separate RIB accounts, both configured the same. I'm using Claws Mail via my ISP using SSL on port 995 and 465. SMTP authentication is enabled. The only plugin enabled is GPG. What else can I provide to assist you?
The other account checked via Claws Mail (BM) functions correctly.
TKS
The other account checked via Claws Mail (BM) functions correctly.
TKS
Another issue has reared its ugly head. I'm having issues using my e-mail client, Claws Mail. I'm using SSL connection and am receiving this time out error.
* Account '[email protected]': Connecting to POP3 server: ruggedinbox.com:995...
[08:48:10] POP3< +OK Welcome to ruggedinbox.com
[08:48:10] POP3> USER [email protected]
[08:48:11] POP3< +OK
[08:48:11] POP3> PASS ********
[08:48:11] POP3< +OK Logged in.
[08:48:11] POP3> STAT
[08:48:11] POP3< +OK 0 0
[08:48:11] POP3> QUIT
** Session timed out. You may be able to recover by increasing the timeout value in Preferences/Other/Miscellaneous.
Sometimes it completes correctly:
* Account '[email protected]': Connecting to POP3 server: ruggedinbox.com:995...
[08:48:06] POP3< +OK Welcome to ruggedinbox.com
[08:48:06] POP3> USER [email protected]
[08:48:06] POP3< +OK
[08:48:06] POP3> PASS ********
[08:48:06] POP3< +OK Logged in.
[08:48:06] POP3> STAT
[08:48:07] POP3< +OK 2 6960
[08:48:07] POP3> UIDL
[08:48:07] POP3< +OK
[08:48:07] POP3> LIST
[08:48:07] POP3< +OK 2 messages:
[08:48:07] POP3> QUIT
[08:48:07] POP3< +OK Logging out.
It appears that there are two messages, however, they do not download. I can connect via Tor or webmail via sm or rc with no issues.
* Account '[email protected]': Connecting to POP3 server: ruggedinbox.com:995...
[08:48:10] POP3< +OK Welcome to ruggedinbox.com
[08:48:10] POP3> USER [email protected]
[08:48:11] POP3< +OK
[08:48:11] POP3> PASS ********
[08:48:11] POP3< +OK Logged in.
[08:48:11] POP3> STAT
[08:48:11] POP3< +OK 0 0
[08:48:11] POP3> QUIT
** Session timed out. You may be able to recover by increasing the timeout value in Preferences/Other/Miscellaneous.
Sometimes it completes correctly:
* Account '[email protected]': Connecting to POP3 server: ruggedinbox.com:995...
[08:48:06] POP3< +OK Welcome to ruggedinbox.com
[08:48:06] POP3> USER [email protected]
[08:48:06] POP3< +OK
[08:48:06] POP3> PASS ********
[08:48:06] POP3< +OK Logged in.
[08:48:06] POP3> STAT
[08:48:07] POP3< +OK 2 6960
[08:48:07] POP3> UIDL
[08:48:07] POP3< +OK
[08:48:07] POP3> LIST
[08:48:07] POP3< +OK 2 messages:
[08:48:07] POP3> QUIT
[08:48:07] POP3< +OK Logging out.
It appears that there are two messages, however, they do not download. I can connect via Tor or webmail via sm or rc with no issues.
Hi chromedome thanks for reporting!
This happens often to us, while using claws-mail and torsocks .. it looks like a lot of exit nodes don't like connections to email ports (smtp / pop / imap).
Usually restarting Tor helps (or forcing it to build a new circuit).
Please let us know if you were not using torsocks with claws-mail!
Jump to: