We Keep Coding

Mail headers missing via SMTP in office365

Here is peculiar case only found on office365 and not on outlook.com.
When I send email with a custom header set (X-ArchiveNum) via O365 SMTP. I am able to send email. But the receiver does not receive the headers when fetched via IMAP. This issue exists only with office365.
Transport transport = getTransport();
MimeMessage forward = new MimeMessage(getSession());
forward.addHeader("X-ArchiveNum", num);
forward.setSubject(sMessage.getSubject());
forward.setFrom(InternetAddress.parse(from)[0]);
forward.setText(body);
forward.saveChanges();
transport.sendMessage(forward, InternetAddress.parse(to));
I see the header being set, when I goto Sent Items folder in my outlook.office365.com account:
I also see the header on the browser when viewed from recipient account. But when I fetch the email via IMAP, I do not see it. I can see the other O365 related headers, but not mine.
Things work as expected from outlook.com (not O365)

Cognito email verification not being sent

I'm experimenting with Cognito but I can't seem to figure out how to get Cognito to send a verification email to a user for them to verify their email address.
This is in my back-end server, where I've received the username, email, and password from a new user. I'm suppressing the message action because I don't want users to receive a temporary password. Instead, I want to set the password to what they've already provided me.
AdminCreateUserRequest adminCreateUserRequest = new AdminCreateUserRequest().withUserPoolId("<user pool ID>")
.withUsername(registerUserRequest.getUsername())
.withUserAttributes(new AttributeType().withName("email")
.withValue(registerUserRequest.getEmail()), new AttributeType().withName("email_verified")
.withValue("false"))
.withMessageAction(MessageActionType.SUPPRESS);
awsCognitoIdentityProvider.adminCreateUser(adminCreateUserRequest);
AdminSetUserPasswordRequest adminSetUserPasswordRequest = new AdminSetUserPasswordRequest().withUserPoolId(<user pool ID>)
.withUsername(registerUserRequest.getUsername())
.withPassword(registerUserRequest.getPassword())
.withPermanent(true);
awsCognitoIdentityProvider.adminSetUserPassword(adminSetUserPasswordRequest);
However, users are never receiving an email to verify their email address. In the user pool configuration, I have "Email" selected under "Which attributes do you want to verify?" and I've verified the email address I'm sending from in SES. Am I missing something here?

If you use AdminCreateUser the account will always be created with a temporary password.
What you actually want is Signup.

Is it possible to get details of the email for which user had replied?

I am using amazon SES to send notification emails in my project. When a user replies back to this email I want to trigger some actions (like a ticket creation or update). Is it possible to know the contents or headers of the email for which user is replying ?

If the replying user's email system supports it (most do), you should receive an In-Reply-To: Header containing the message-id of the email you sent. If you kept that message (along with the message id) you can use this to retrieve original email.
Sometimes the Refereces: Header might be useful as well

Securing REST Web Service using token (Java)

This question is in some way related to the below linked question. However, I need a little more clarity on some aspects and some additional information. Refer:
REST Web Service authentication token implementation
Background:
I need to implement security for a REST Web Service using token
The webservice is intended for use with Java client. Hence, form
authentication and popups for credentials are not useful.
I'm new to REST security and encryption
This is what I have understood till now:
For first request:
User establishes https connection (or container ensures https using
301)
User POSTs username and password to login service
If credentials are valid we:
Generate a random temporary token
Store the random token on server mapping it to actual username
Encrypt the token using a symmetric key only known to server
Hash the encrypted token
Send the encrypted token and the hash to the client
For subsequent requests:
Client sends this encrypted token and hash combination (using
username field of basic?)
We make sure the encrypted token is not tampered using the hash and
then decrypt it
We check the decrypted token in the session-tracking-table for a
not-expired entry and get the actual username (expiry to be managed
by code?)
If the username is found, based on allowed roles, allowed operations
are configured
More details:
Since client is a java client, the first request can be a POST
containing the credentials. However, this looks like it may expose
the credentials before the https gets established. Hence should
there be a dummy GET to a secured resource so that https is
established first?
Assuming above is required, the second request is a LoginAction POST
with credentials. This request is handled manually (not using
container's authorisation). Is this right?
The above LoginAction returns the user the combination of encrypted
token + hash
User sets it to the header that is used by BASIC authentication
mechanism (field username)
We implement a JAASRealm to decrypt and validate the token, and find
the roles allowed
The rest of authorisation process is taken care of by the container
with the WebResourceCollection defined in the web.xml
Is this the correct approach?

Why not simplify it to the following?
For first request:
User establishes HTTPS connection to server (service does not listen on any
other ports) and POSTs credentials to login service.
Server replies with HSTS header to ensure all further communication
is HTTPS.
If credentials are valid we:
Generate a random temporary token which is securely generated using a CSPRNG. Make this long enough to be secure (128 bit).
Store the random token on server mapping it to actual username.
Send the random token to the client
For subsequent requests:
Client sends token in a custom HTTP header over HTTPS.
Token is located in the DB and mapped to the username. If found access is configured based on allowed roles and allowed operations.
If not found user is considered unauthenticated and will have to authenticate with the login service again to get a new token.
On the server side the token will be stored with an expiry date. On each access to the service this date will be updated to create a sliding expiration. There will be a job that will run every few minutes to delete expired tokens and the query that checks the token for a valid session will only check those that have not deemed to have expired (to prevent permanent sessions if the scheduled job fails for any reason).
There is no need to hash and encrypt the tokens within the database - it adds no real value apart from a touch of security through obscurity. You could just hash though. This would prevent an attacker that managed to get at the session data table from hijacking existing user sessions.

The approach looks ok. Not very secure.
Let me highlight some of the attacks possible with the request.
Man-In-the-middle attack in a POST request, the user can tamper with the request and server does not have any way to ensure the data is not tampered.
Replay attack: In this, the attacker does not tamper with the request. The attacker taps the request and sends it to the server multiple times in a short duration, though it is a valid request, the server processes the request multiple times, which is not needed
Please read about Nonce.
In the first step, the user sends his credentials i.e username and password to the login service and if you have a web based application that also uses the same password it might be dangerous. If in case password in compromised, API and web everything is exposed, please use a different PIN for API access. Also, ensure decrypted token as specified by you, expires after a certain time.
Ensure the service (application server) tomcat. jboss never returns a server page in case of internal error, this gives the attacker extra information of the server where the app is deployed.
-- MODIFIED BASED ON SECOND POST --
Yes your correct if your using mutual SSL, but in case its a one way access you don't have the client certificates. It would be good if you just double ensured everything in the request, just like signed (signature) SOAP, one of the strong data transfer mechanism. But replay attack is a possibility with HTTPS, just handle that. Rest use tokens encryption is good. And why not ask the client to decrypt the token with the password and return the output of the decryption by this you can validate the output, if it is present in your database ? This approach the user does not send the password over the wire even if it is HTTPS ?

Using Mailjet API in Grails application for sending mails

I want to integrate Mailjet API in Grails application for sending mails, I have already used ASYNC mail API for sending mail in grails, in this api , I need to give configuration parameters in config.groovy. Now as I am using Mailjet for sending mails, so I need to give Mailjet SMTP settings in config.groovy, so I give as follows :
grails {
mail {
host = "in.mailjet.com"
port = 465
username = "xxx#gmail.com"
password = "xxx"
props = ["mail.smtp.host": "in.mailjet.com",
"mail.smtp.socketFactory.port": "465",
"mail.smtp.socketFactory.class": "javax.net.ssl.SSLSocketFactory",
"mail.smtp.auth":"true",
"mail.smtp.port": "465",
"mail.smtp.user": "API key of mailjet",
"mail.smtp.password": "secret key of mailjet"]
}
}
Here is the example of sending mail using java code
What am I doing wrong?

username and password have to contain your api key and the api secret, not the credentials
that you use to log into the web site.
Using mail.smtp.host as a property is redundant and should not be necessary.