mirror of
https://github.com/anonaddy/anonaddy.git
synced 2026-04-25 14:15:53 +03:00
[GH-ISSUE #282] count of forwarded msgs *decreased* #243
Labels
No labels
bug
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/anonaddy#243
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @bruceleerabbit on GitHub (Mar 27, 2022).
Original GitHub issue: https://github.com/anonaddy/anonaddy/issues/282
I created a new alias to use for a new web account. The server of the new web account immediately sent a verification code to the new anonaddy alias. I refreshed the alias list and the count of forwarded messages was “1”. The msg never arrived. So my first thought was that the recipient mail server blocked the msg (note that I am using “blocked” generically since I do not know if the recipient mail server refuses suspect connections or if it accepts spam msgs then simply neglects to deliver them to the normal inbox).
Since I’m working blind (unable to know at which point the msg is being lost), I ordered the web service to send another verification code. Then I refreshed the page that lists my aliases. I expected the forwarded count to go to “2”, but instead it went to “0”!
Impossible. The count should never decrease. Then I came across bug https://github.com/anonaddy/anonaddy/issues/264 .
So apparently code was introduced to decrement the forwarded count. The bug 264 fix actually makes it more of a mystery what happened. The row now shows 0 forwarded and 0 blocked. Since we assume that Anonaddy wouldn’t blackhole a message, the zeros falsely implies that the sender never made any attempt to send anything.
The “blocked” count is vague. Does that mean msgs that Anonaddy blocked due to a user setting an alias to inactive, or is it due to a blocked delivery by the receiving server? Normally I would assume it's the former: msgs blocked by anonaddy.
In any case, having a row of all zeros impies that the sender made no attempt which is quite likely not the case in the case at hand because it was an automated verification msg. Users expect the “forwarded” column to count forwarding attempts, not necessarily successes. This is because some receiving servers will accept a msg then reject it later (it’s a bad practice but it happens). And in that case, Anonaddy would not know about delayed rejects.
The best fix is to have more columns. E.g.
To keep the column headers short, perhaps a hover msg could say “msgs blocked by Anonaddy” when the user hovers over “blocked”.
Also in the event that a receiving server refuses a msg from Anonaddy, what does Anonaddy do with that msg? It would be useful if users could get access to refused msgs. Perhaps if you stored them for premium accounts? Or sent them to a backup recipient address? I’m just brainstorming at this point but there should be some mitigation for data loss.
@willbrowningme commented on GitHub (Mar 29, 2022):
Please could you send me an email with the exact alias that this happened for so that I can investigate it for you. It sounds like the message encountered an error and was failed to be forwarded from AnonAddy to your recipient.
The blocked count refers to any incoming messages that AnonAddy blocks becaue the alias is either deactivated or deleted.
I agree that I need to make the terminology clearer, I will try to improve all of this when I redesign the user interface in the next few months.
If AnonAddy tries to forward a message but it is refused by the recipient then that is classed as a failed delivery and should show up on the failed deliveries page. I do plan to add an opt-in option to temporarily store (perhaps encrypted with the recipient's public key) any failed messages so that they can be manually downloaded.
I may also add the backup recipient option too.
@willbrowningme commented on GitHub (May 26, 2023):
Should be resolved now, this was related to failed deliveries.