BitShares Forum
Main => General Discussion => Topic started by: xeroc on December 15, 2015, 11:53:42 am
-
Dear community,
this is my 10,000th post in this forum and I have prepared something special to show my passion about BitShares (and the
Graphene Technology) and try to establish a profitable business in this ecosystem:
Two Factor Authentication
I would like to introduce a second factor authentication service for the BitShares network. It will require users to
request a new account by sending a memo and a registration fee to on of our accounts. To secure your new account, We
will make heavy use of "proposed transactions".
Note that we are currently running in a beta testing phase and hence recommend to only use small amounts of
your money to test this system. It is also required to use a patched cli_wallet for now. I hope to see proposed
transactions in the GUI wallet somewhen in Q1/2016. Until then I can only recommend very advanced users to try out this
service.
Costs for the users
Providing increased security for your funds is a service that cannot be offered "for free". Hence, we need to cover our
costs and find a way to fund future development. During the beta testing we will offer our service at a cost of
0.4% of the transfer amount and 200 BTS account registration fees (see below).
Only during the beta testing, the service fee will be 0.0%. Accounts will be migrated from the beta testing once
we eliminated all issues yet to be found.
Procedure (for discussion)
Registration
- A customer sends a 200 BTS from his account to the account peermit-reg and puts his email address in the memo
- These funds will be used to register your new "secured account" (of which YOU will be the only owner)
- We will send you an email containing the secured accounts' name
Funding your secured account
Your secured account can be funded similar to any other account: Just use the account name you have received by email.
You should take a look at the permissions tab to see that YOU are the sole owner of the account and are among the list
of active permissions with half the weight that is required by the threshold.
Spending funds
- To spend funds from the secured account one of these conditions have to be
met:- your OWNER key signs the transaction
- your ACTIVE key AND our ACTIVE key sign the transaction
By this, it is ensured that- you control the account and can opt-out of the service
- your active key alone cannot spend funds of that account unless you also have access to the mail account
- You propose a transaction that spends from the secured account
- You approve your own proposal
- We notice that proposal and send an email verification token to your registered mail address
- Upon clicking the verification link on the mail, we will sign the proposal
- After the expiration time your proposal will validate and the proposed transaction will execute.
Security aspects
- The customer can Opt-Out at any time since they own the "owner" authority
- Transactions need TWO signatures (ours and yours) or your owner authority
- Owner key of our multisignature account is stored offline and never touched an internet-connected device
- Active Key of our multisignature account can (and will be) rotated on a regular basis to ensure that a compromised key cannot sign future proposals.
- Access to the signing machine is restricted by VPN and API-control restrictions
- If the proposal is not verified, the funds will not move (of course)
- This scheme allows to "combine" several multisig schemes with additional required authorities by 3rd parties
- Aribtrary expiration (e.g. 24h). If the proposal is not verified, the funds will not move (of course)
Attack scenarios
- Our multisignature account is compromised:
Since only the active key can be compromiese (owner key is 'very cold') we can remove it from our accounts authority
and place a new one leaving the attacker with a worthless key. - Your active key is compromised:
An attacker would need to also conquer your second factor (currently: email) to have any transaction approved. - Your original account's owner key is compromised:
This will also compromise your secured account since the owner of it is identical to your original account. Hence,
make sure to have your brainkey and owner prive key secured (offline) and only use your active key! Also note, that
you can change the owner account to something else at your own risk.
Known Issues
Since the GUI is not yet capable of producing proposals, we currently only offer a python call that can propose a
transaction as required (see below) Another inconvenience for some users may be that besides proposing a transaction,
users must manually approve their own proposed transaction
There is currently a pending patch for proposing a transaction that needs to be installed into the cli_wallet first:
git remote add graphene https://github.com/cryptonomex/graphene
git fetch graphene
git cherry-pick 7a5c5c4
make cli_wallet
Python library for testing
I wrote a new Proposal class to make it easier for people to play around and/or integrate. This class does not yet take
the service fee into account but will do so once we are out of beta.
Installation
git clone https://github.com/xeroc/python-grapehenelib
cd python-grapehenelib
python3 setup.py install --user
pip3 install
pip3 install --user asyncio autobahn requests
Note that you need two active keys installed: a) an active key that can pay for
the proposal and b) the active key of your secured account because you need to
approve your own proposal.
Demo code:
import time
import json
from grapheneapi import GrapheneAPI, GrapheneWebsocket
from grapheneextra.proposal import ProposalManagement
class Config() :
witness_url = "ws://localhost:8090/"
witness_user = ""
witness_password = ""
wallet_host = "localhost"
wallet_port = 8092
wallet_user = ""
wallet_password = ""
proposer_account = "fabian" # this account proposes a proposal
from_account = "fabian-secured" # this is the secured account
to_account = "fabian" # target account
if __name__ == '__main__':
config = Config
## New instance of proposal management
propmang = ProposalManagement(config)
## Propose a transfer transaction on the chain (proposer_account must fund the tx fee)
proposal = propmang.propose_transfer(config.proposer_account, config.from_account, config.to_account, 333.5, "BTS", expiration=60)
## Print the proposal transaction
print(json.dumps(proposal,indent=4))
## Wait for the Proposal to verify on the blockchain
time.sleep(10)
## Approve proposals that require from_account's approval (does not ask for manual confirmation, yet!)
propmang.approve_available_proposals(config.from_account, config.proposer_account)
FAQ
Q: Why register new accounts
A: For sake of convenience. It is still more difficult for users to set another
active authority than to send funds with a mail address in the memo to a given
account.
Q: Why is their a public key as owner of the secured account and not my origin account?
A: Simply because if it was your account name, anyone with your active key is
owner of the secured account. By putting the owner key of your original
account as owner, your secured account's owner key is "as secure as your
original account".
For those that read through the whole post: Thank you :D
Hope to hear your thoughts about the over all process!
Cheers
-- Fabian
-
Top notch !!
-
Looking forward to playing around with this. It is a great use case for the sophisticated key structures offered by Graphene. Awesome work and congrats(?) on your 10 thousandth post!
-
+5% :D
-
Very good stuff. +5%
-
Account created.
Building patched cli_wallet.
Need more help on how to create proposal via cli_wallet.
By the way, the owner key and active key of my old account are same, so keys of the new account are same as well, I think it will be problematic.. ::) how to solve?
-
Account created.
Building patched cli_wallet.
Need more help on how to create proposal via cli_wallet.
Read the part "Python library for testing" of the announcement. It shows a demo code
By the way, the owner key and active key of my old account are same, so keys of the new account are same as well, I think it will be problematic.. ::) how to solve?
Yhea .. those accounts are VERY old (maybe even keyhotee founders) .. I can't fix that from my end and decided to still register the accounts accordingly. .
Since you are the sole owner of both accounts you can set your keys as you wish ..
the easiest way would be to update the active key of your original account and only work with that one from now forward ..
make sure to keep the private key for the owner authority as secure as humanly possible
-
+5% Sounds great xeroc!
Glad to see a 2FA scheme not based on cell phones, which a very porous and insecure b/c of the openness at some levels of the comm. stack required for multi-carrier interoperability. That risk may be low, but it is difficult to evaluate. I am very paranoid and would never rely on the security of any 2FA based on cell phones UNLESS I rooted the phone and was very confident of the ROM and other tools to protect the device's security. Even with that, I still have reservations about security compromise at the hardware level.
I presume that the memo field used to communicate the email account is not visible without the transaction private key to unlock?
The use of VPN is great, consider chaining more than one together from 2 or more vendors for added protection.
Consider using a trusted secure email provider like startmail (or setup your own on a VPS) if you haven't already. Only connect to that server via VPN. Email is probably your weakest link in terms of security vulnerabilities.
:) Oh and condrads on your 10,000th post! I only just recently past 10% of that and got into the triple digits :)
-
Glad to see a 2FA scheme not based on cell phones, which a very porous and
insecure b/c of the openness at some levels of the comm. stack required for
multi-carrier interoperability. That risk may be low, but it is difficult to
evaluate. I am very paranoid and would never rely on the security of any 2FA
based on cell phones UNLESS I rooted the phone and was very confident of the ROM
and other tools to protect the device's security. Even with that, I still have
reservations about security compromise at the hardware level.
I hear you .. and I have my phone rooted as well (in fact I have another ROM
installed)
I presume that the memo field used to communicate the email account is not visible without the transaction private key to unlock?
Correct. Actually, the key required (by default) to decode the memo is a shared
secret of your pub key and other parties priv key .. or vice versa.
The use of VPN is great, consider chaining more than one together from 2 or more
vendors for added protection.
Indeed .. Once we made some profit to pay for even more security, this will
happen. I have also started to write transaction signing process in python
directly .. that way we don't need to run a cli_wallet at all and can harden
the system even more.
Consider using a trusted secure email provider like startmail (or setup your own
on a VPS) if you haven't already. Only connect to that server via VPN. Email is
probably your weakest link in terms of security vulnerabilities.
Peermit.com is hosted solely on a fat machine. We have our own mail server of
course and we plan to add PGP signing for all messages eventually.
Keep in mind that the current beta is really just a MVP or proof-of-concept
(with security already in mind). Give us some more time and we will make it even
stronger :)
-
Very very nice. If someone wanted to add your account active key to their existing account in a 2 of 2 scheme would you support that?
How are you planning on taking your fee? You can't stop someone from sending to this account, and if they want they can use their owner key to withdraw without 2fa. Are you planning on charging a portion for each spend from this account that uses the 2fa system?
-
Very very nice. If someone wanted to add your account active key to their existing account in a 2 of 2 scheme would you support that?
We can support that aswell .. actually it was my first idea to do it that way
and have the corresponding routines implemented already. However, it is way
easier for most users to get a new account registered with the correct
authorities already .. plus, peermit.com sees referral income.
In theory we can even arrange a different scheme for every user.
For instance, we could have premium member ships that are cheaper.
Or we could use instancly approve any trading activities but require 2FA for
transfers of USD and BTS, but not BTC :)
Possibilities are endless :)
How are you planning on taking your fee? You can't stop someone from sending to
this account, and if they want they can use their owner key to withdraw without
2fa. Are you planning on charging a portion for each spend from this account
that uses the 2fa system?
We have two options:
Either we only approve transactions that have a second transfer in them that pay
the service fee to our account,
or we demand withdrawal_permissions from an account and withdraw the service fee
monthly, weekly ...
Alternatively, we could even use a prepayed scheme and have people preload an
account at peermit.com .. though that would not be my preferred choice
What would you prefer?
-
Very very nice. If someone wanted to add your account active key to their existing account in a 2 of 2 scheme would you support that?
How are you planning on taking your fee? You can't stop someone from sending to this account, and if they want they can use their owner key to withdraw without 2fa. Are you planning on charging a portion for each spend from this account that uses the 2fa system?
Interesting thought puppies. If so it's similar to the move the multibit wallet did in their Multibit HD version, where they take a small fee in addition to the bitcoin transaction fee on every transaction performed from that wallet. The problem is, you can't opt-out, it's not a donation it is a mandatory fee. It's worse than a license fee, it's more like an income tax!
@xeroc, if you plan on taking a cut of transfers, no matter how small, consider making it an optional donation. Even if the default is ON, allowing it to be turned off and fully disclosing that this is any part of your funding model is the ethical thing to do. I see reviews and info about Multibit that fail to disclose the mandatory fee they take to fund development (i.e. like on cryptocompare.com) which I think is manipulative.
-
Wow. Nice Xeroc. So how have you figured out the exact amount that will be charged?
-
Interesting thought puppies. If so it's similar to the move the multibit wallet
did in their Multibit HD version, where they take a small fee in addition to the
bitcoin transaction fee on every transaction performed from that wallet. The
problem is, you can't opt-out, it's not a donation it is a mandatory fee. It's
worse than a license fee, it's more like an income tax!
To make it clear again. In this scheme you can OPT-OUT at any time.
I want to have it that way to not end up with a service that needs to be run
indefinitely. Every user can simply opt out by importing the owner key of the
original account. That of course also opens up an attack vector: If the original
account's owner key is compromised, so will the secured account!!!
@xeroc, if you plan on taking a cut of transfers, no matter
how small, consider making it an optional donation. Even if the default is ON,
allowing it to be turned off and fully disclosing that this is any part of your
funding model is the ethical thing to do. I see reviews and info about Multibit
that fail to disclose the mandatory fee they take to fund development (i.e. like
on cryptocompare.com) which I think is manipulative.
Good point. I could have a "free" plan with some restrictions and ask customers
to upgrade at a fee to gain access to "more features" or faster approvals or
somthing similar. Good idea. I will keep it in mind!
-
Wow. Nice Xeroc. So how have you figured out the exact amount that will be charged?
The reigstration fee of 200 BTS is just a little to pay for the account registration fee (50 BTS) and have some funds available initially to approve proposals.
The 0.4% fee is just an idea and not fixed yet .. However, I wanted to show people the progress I am making and let them play around it ..
Not sure how to deal with the business/profit related issues yet .. that's why I started with a bold 0.4% flat ...
Any suggestions on how to please the customers and still have the service be profitable?
-
+5% +5% +5%
I'll test in once it's available in the gui
-
Nice!! This is a valuable service and excellent hint of graphene's possibilities. This is the tip of the iceberg.
Your beta strategy is great and I'm glad you moved forward without waiting for others.. very inspiring!
-
I would suggest a flat rate, or a series of flat rates based upon service level. Maybe have a free option that only works with an account registered by you so you get the referral income, and there is a 30 minute delay in transaction processing. Then have a rate of let's say 800 bts a month (set as a recurring transaction) for an unlimited account that you registered. Then maybe 1000bts a month to integrate an existing account. Provide alternate means of verification. Email, text, other online messaging, Google.
Perhaps the differentiator for free vs paid accounts could simply be the ability to modify parameters. Or rate limiting.
-
Wow. Nice Xeroc. So how have you figured out the exact amount that will be charged?
The reigstration fee of 200 BTS is just a little to pay for the account registration fee (50 BTS) and have some funds available initially to approve proposals.
The 0.4% fee is just an idea and not fixed yet .. However, I wanted to show people the progress I am making and let them play around it ..
Not sure how to deal with the business/profit related issues yet .. that's why I started with a bold 0.4% flat ...
Any suggestions on how to please the customers and still have the service be profitable?
nice approach!
i think 0.4% will be really expensive, considering this is just a kind of "insurance"
i would say you should try to calculate how many accounts you can handle automated with your computer etc. and make a yearly or monthly fee.
say, you will charge 15 bitUSD for 1 year. with this pricing you will make more with small accounts, but less with higher accounts. But i assume in the long run,
you would have much to do with not so used accounts and from my expierence theses accounts will cost you much more time then the big accounts, because they need more
attention.
maybe, you can think also about future services you can charge extra fees etc.
could you give me a hint how i can start the client wallet on windows? i am trying for a couple of days, but my tech is to low to understand it. i think the node is running, but i can't do anything with the client wallet.
-
Fantastic news @xeroc and what a way to celebrate your 10,000th post!
This will be extremely useful for us at Bitcash so really glad you are doing this!
-
+1
Great work xeroc!
-
Hmm.. @xeroc Just found that I hadn't got any email..
-
I played with this today and it works well. Certainly opens the door for other ideas/uses. Graphene is the best kept secret in crypto.
-
Hmm.. @xeroc Just found that I hadn't got any email..
Have you checked spam folder? I see a gmail.com address for your account and a registered secured account ..
-
FYI, I am taking down the proposal-monitoring script until another issue is fixed .. I will keep you posted
That that want to test the 2FA authentication will need to wait a few more days ..
sorry for any inconveniences
I'll keep you posted
-
Hmm.. @xeroc Just found that I hadn't got any email..
Have you checked spam folder? I see a gmail.com address for your account and a registered secured account ..
No new mail in spam folder.. and yes I saw that account registered (from the transaction history of peermit-reg).
FYI, I am taking down the proposal-monitoring script until another issue is fixed .. I will keep you posted
That that want to test the 2FA authentication will need to wait a few more days ..
sorry for any inconveniences
I'll keep you posted
Sent another 200BTS to peermit-reg before seen this post.. :P will wait.. wish you fix the issue soon +5%
BTW better update OP if not did.
-
Hmm.. @xeroc Just found that I hadn't got any email..
Have you checked spam folder? I see a gmail.com address for your account and a registered secured account ..
No new mail in spam folder.. and yes I saw that account registered (from the transaction history of peermit-reg).
FYI, I am taking down the proposal-monitoring script until another issue is fixed .. I will keep you posted
That that want to test the 2FA authentication will need to wait a few more days ..
sorry for any inconveniences
I'll keep you posted
Sent another 200BTS to peermit-reg before seen this post.. :P will wait.. wish you fix the issue soon +5%
BTW better update OP if not did.
You are right .. it seems gmail blocked that mail .. at least the deny to take that mail several times
It should have went through by now.
I'll investigate
-
nice approach!
i think 0.4% will be really expensive, considering this is just a kind of "insurance"
i would say you should try to calculate how many accounts you can handle automated with your computer etc. and make a yearly or monthly fee.
say, you will charge 15 bitUSD for 1 year. with this pricing you will make more with small accounts, but less with higher accounts. But i assume in the long run,
you would have much to do with not so used accounts and from my expierence theses accounts will cost you much more time then the big accounts, because they need more
attention.
Thanks for the input.
Of all the aspects of creating a business, dealing with revenue and expenses are
the most diffcult once for me.
maybe, you can think also about future services you can charge extra fees etc.
That is the plan.
could you give me a hint how i can start the client wallet on windows? i am
trying for a couple of days, but my tech is to low to understand it. i think the
node is running, but i can't do anything with the client wallet.
you need to open the rpc port in the witness node:
./programs/witness_node/witness_node --rpc-endpoint="192.168.0.100:8090"
and can then connect your cli_wallet with that witness with:
./programs/cli_wallet/cli_wallet --server-rpc-endpoint="ws://192.168.0.100:8090"
Note that you need to import the keys you want to use in the cli_wallet manually
using
import_key <account> "<wif>"
Some common calls are given here:
http://docs.bitshares.eu/integration/often-used-calls.html
Cheers
-- Fabian
-
is this re-enabled yet Xeroc. I was hoping to
play with it help test a little bit today.
-
Yes it is .. however i will be unavailable over the weekend to give you any support .. I'll add the instruction (that i removed for security reasons) in a few minutes
//edit: I added the instructions .. have fun
-
is this re-enabled yet Xeroc. I was hoping to play with it help test a little bit today.
I just noticed your first trial of this service and you ran into an edge case that I probably need to check on registration to make the users aware of it.
You probably wondered why your transaction went through though you have just made a simple transaction (no proposal) and Peermit did not need to approve it.
The edge case is a result of founder accounts having an identical OWNER and ACTIVE key.
so:
- the owner key of puppies is the owner key of puppies-secured (as it should be as per our definition)
- the active key of puppies is IDENTICAL to its owner key (that shouldn't be the case for newly created accounts)
Hence, whenever you transfer funds from puppies-secured, your wallet knows about the OWNER key and thus OVERWRITES any active authority requirements (as it should be)
If you puppies active key wasn't identical to the owner key, the transfer signature wouldn't be sufficient to transfer funds, you would get a "missing active authority" warning and would require to PROPOSE the transfer .. only then will I see a proposal an send you a mail
Makes sense to you?
Hopefully this issue can a) be address by checking the keys on registration and sending out a mail and b) by changing the active key of your original account (which will soon be available as a simple button click)
-
is this re-enabled yet Xeroc. I was hoping to play with it help test a little bit today.
I just noticed your first trial of this service and you ran into an edge case that I probably need to check on registration to make the users aware of it.
You probably wondered why your transaction went through though you have just made a simple transaction (no proposal) and Peermit did not need to approve it.
The edge case is a result of founder accounts having an identical OWNER and ACTIVE key.
so:
- the owner key of puppies is the owner key of puppies-secured (as it should be as per our definition)
- the active key of puppies is IDENTICAL to its owner key (that shouldn't be the case for newly created accounts)
Hence, whenever you transfer funds from puppies-secured, your wallet knows about the OWNER key and thus OVERWRITES any active authority requirements (as it should be)
If you puppies active key wasn't identical to the owner key, the transfer signature wouldn't be sufficient to transfer funds, you would get a "missing active authority" warning and would require to PROPOSE the transfer .. only then will I see a proposal an send you a mail
Makes sense to you?
Hopefully this issue can a) be address by checking the keys on registration and sending out a mail and b) by changing the active key of your original account (which will soon be available as a simple button click)
Thats what I figured. Thats why I did the 1k bts test back to dele-puppy. I have now adjusted the owner key of puppies-secured to a cold private key. Now the fun testing begins. I am not exactly sure how to use your python class, but the trial and error is about to begin.
-
Got it. Had to do two attempts. I was too slow to get it done in 60s the first time. Absolutely awesome work xeroc.
-
No email still..
-
No email still..
I have noticed that google didnt accept my mail for some policy reason but thought it was delivered by now. I'll take look at the logs when back.
In the meantime there should be an account created with your username+"-secured".
before using it check that the owner key is the same and that the active permissions are ok .. you can also take a loom at the history of peermit-reg to find the proper account.
Sorry for the troubles
-
No email still..
I have noticed that google didnt accept my mail for some policy reason but thought it was delivered by now. I'll take look at the logs when back.
In the meantime there should be an account created with your username+"-secured".
before using it check that the owner key is the same and that the active permissions are ok .. you can also take a loom at the history of peermit-reg to find the proper account.
Sorry for the troubles
Yes, I noticed the new account created and tested with it before post above, but if I understood correctly without notification email I can't confirm my transfer (the 2nd step). Made one more test just now but haven't got any email yet as well.
Thanks.
abit-2fa-secured Created a proposal 3 minutes ago
abit-2fa-secured Created a proposal yesterday
-
@abit: This is odd .. in the beginning I received a lot of these from google:
Dec 15 14:54:35 panel postfix/smtp[9737]: 116C36320FF: to=<mail-of-a-bit-redacted@gmail.com>, relay=alt1.gmail-smtp-in.l.google.com[74.125.130.27]:25, delay=380, delays=376/0.01/2/1.6, dsn=4.7.0, status=deferred (host alt1.gmail-smtp-in.l.google.com[74.125.130.27] said: 421-4.7.0 [176.9.234.163 15] Our system has detected an unusual rate of 421-4.7.0 unsolicited mail originating from your IP address. To protect our 421-4.7.0 users from spam, mail sent from your IP address has been temporarily 421-4.7.0 rate limited. Please visit 421-4.7.0 https://support.google.com/mail/answer/81126 to review our Bulk Email 421 4.7.0 Senders Guidelines. 66si2081703pfo.92 - gsmtp (in reply to end of DATA command))
Dec 15 15:04:36 panel postfix/smtp[12130]: 1C8E2632105: to=<mail-of-a-bit-redacted@gmail.com>, relay=alt1.gmail-smtp-in.l.google.com[74.125.130.27]:25, delay=970, delays=966/0.01/2.6/1.2, dsn=4.7.0, status=deferred (host alt1.gmail-smtp-in.l.google.com[74.125.130.27] said: 421-4.7.0 [176.9.234.163 15] Our system has detected an unusual rate of 421-4.7.0 unsolicited mail originating from your IP address. To protect our 421-4.7.0 users from spam, mail sent from your IP address has been temporarily 421-4.7.0 rate limited. Please visit 421-4.7.0 https://support.google.com/mail/answer/81126 to review our Bulk Email 421 4.7.0 Senders Guidelines. w69si905571ywd.223 - gsmtp (in reply to end of DATA command))
Dec 15 15:04:37 panel postfix/smtp[12129]: 116C36320FF: to=<mail-of-a-bit-redacted@gmail.com>, relay=alt1.gmail-smtp-in.l.google.com[74.125.130.27]:25, delay=981, delays=977/0.01/2.8/1.7, dsn=4.7.0, status=deferred (host alt1.gmail-smtp-in.l.google.com[74.125.130.27] said: 421-4.7.0 [176.9.234.163 15] Our system has detected an unusual rate of 421-4.7.0 unsolicited mail originating from your IP address. To protect our 421-4.7.0 users from spam, mail sent from your IP address has been temporarily 421-4.7.0 rate limited. Please visit 421-4.7.0 https://support.google.com/mail/answer/81126 to review our Bulk Email 421 4.7.0 Senders Guidelines. i128si902472ywf.271 - gsmtp (in reply to end of DATA command))
but later on I get
Dec 15 15:24:33 panel postfix/smtp[14942]: 1C8E2632105: to=<mail-of-a-bit-redacted@gmail.com>, relay=gmail-smtp-in.l.google.com[173.194.65.27]:25, delay=2166, delays=2166/0.01/0.13/0.78, dsn=2.0.0, status=sent (250 2.0.0 OK 1450189473 b8si2259459wjx.62 - gsmtp)
Dec 15 15:24:33 panel postfix/smtp[14941]: 116C36320FF: to=<mail-of-a-bit-redacted@gmail.com>, relay=gmail-smtp-in.l.google.com[173.194.65.27]:25, delay=2177, delays=2177/0.01/0.14/0.78, dsn=2.0.0, status=sent (250 2.0.0 OK 1450189473 v9si2220041wje.152 - gsmtp)
Dec 18 20:34:08 panel postfix/smtp[16107]: 217266320E0: to=<mail-of-a-bit-redacted@gmail.com>, relay=gmail-smtp-in.l.google.com[173.194.65.27]:25, delay=1.2, delays=0.04/0.05/0.18/0.96, dsn=2.0.0, status=sent (250 2.0.0 OK 1450467248 d10si27790295wje.120 - gsmtp)
Dec 18 20:34:18 panel postfix/smtp[16107]: AEC596320E0: to=<mail-of-a-bit-redacted@gmail.com>, relay=gmail-smtp-in.l.google.com[173.194.65.27]:25, delay=0.32, delays=0.04/0/0.1/0.17, dsn=2.0.0, status=sent (250 2.0.0 OK 1450467258 n10si27832541wja.51 - gsmtp)
Dec 19 13:09:02 panel postfix/smtp[28477]: AC5A36320E2: to=<mail-of-a-bit-redacted@gmail.com>, relay=gmail-smtp-in.l.google.com[74.125.24.27]:25, delay=1.2, delays=0.19/0.04/0.24/0.76, dsn=2.0.0, status=sent (250 2.0.0 OK 1450526942 g66si20131631wmf.82 - gsmtp)
It says that google took the mail and deliver it.
-
Hmm.. I checked again and found them at last.
I'm automatically forwarding all mails to that address to another mailbox, however gmail filtered the mails as spam and didn't forward them for me, so they are left in the spam folder of the original address. Annoying. I added a few new filters just now, wish it helps.
Thanks for your help +5%