We Keep Coding

JavaMail - Mask "from" address

I have a piece of software I am developing that includes user accounts and login/passwords. For password storage/protection, I am using an asymmetric salt+hash system, and thus, if a user forgets their password, I would like the software to send a password reset link to the user's email address.
My question is this: is it possible to send this email from an address that does not actually exist (like do-not-reply#myproject.com)? Alternatively, is there a way to send it from a real email address but to mask the "from" address and make it appear to the recipient as do-not-reply#myproject.com even if it truly came from myemail#gmail.com?

Yes, you can send the e-mail to appear to come from any address. It is important to recognize that there are two 'from' addresses - the envelope sender is often not displayed to the recipient but indicates the server that is sending the message. The 'from' address is different and is specified in the message headers. As this is what what the recipient sees, it sounds like you simply need to customize your 'from' address header in the message.
Note: Some users will have e-mail servers that require proof that your server is authorized to send e-mail from the domain in the 'from' header. You can do this with an SPF record on the mydomain.com DNS zone file.

Is it possible to mask/spoof email address while sending mail in Java

In simple word, whenever I will send mail to anyone (within same mail server) it should appears some fake email address i.e. fakemail#gmail.com but, when they reply to this mail, it should come to my actual email address that is realname#gmail.com.
Note: My both email addresses will use same domain name, but only difference will be fake and real username for that email. I needed for the privacy issue. So, that nobody can reply to my mail directly until I send any mail to them.

Ask your mail server administrator to setup an email forwarding for you.
This is not a Java specific question. What you are asking for is called an
Email alias, and is a standard functionality on mail servers.

You can use a fake "from:" field and a valid "reply-to:" field, but the only people that will be fooled by this are people who would not know how to send spam anyway.

Even if you can (see below) mask the From field, you are giving away your email address in the Reply-To field, so you are still revealing your email address. (And if you weren't, it wouldn't be possible to reply.) So go with #Anony-Mousse and find a proper solution.
Now, please note that there are two "from" fields: one in the SMTP envelope and another in the message data.
It is quite uncommon for current mail servers to let you fake the SMTP from, though it may be possible if the server is using raw SMTP without authorization.
You are more likely to be allowed to send an email with a custom "From" in the message body (which is the one mail clients display, unless you look att all headers). However, the mail server may require that it matches the user you authenticated as.

Can you send a message to an email account through an alias in javamail?

Example:
Account account#gmail.com
Alias ​​account
I want to send the message as follows:
m_simpleMessage.setRecipient(
SMTPMessage.RecipientType.TO,
new InternetAddress ("account")
);
Is it possible to send an email using an alias?

Is possible send email using an alias?
Assuming that you are talking about some kind of alias defined in Exchange, then I think that the answer is no. Or at least, not unless your application has the smarts to lookup aliases in Exchange and translate them to real email addresses ... before it sets the recipient address.

How can I send two emails via javamail such that outlook will put them in the same conversation?

At some point, I've sent an email and it is processed and received by an exchange server and then viewed by an outlook client. At a later point, I send another email where it is a reply/related to the 1st email. I want outlook to know that they are related and group them together when I group emails by conversation.
A couple of caveats:
I won't have access to the 1st email's message object to reply off of.
I will have the subject, messageID, and body of the first email when composing the 2nd email.
I've tried adding the "in-reply-to" and "references" header fields in the 2nd email, but outlook will not conversate them. Thunderbird and Gmail will thread them appropriately, though.

When grouping messages into a Conversation, Outlook will most likely not use the header fields but rather the subject line. It will ignore words like Fw: and Re:.
Try prepend a Re: to the first message subject and use this as second message subject.
Ref: http://lifehacker.com/157042/make-outlook-thread-conversations-like-gmail

How to set the Return-Path to an email address other than Sender address using JavaMail?

How to set the Return-Path to an email address other than Sender address using JavaMail?

The code below does what you want, and does it in the correct way. Reread what you yourself posted in the comment
From: RFC2821: 4.4 Trace Information
When the delivery SMTP server makes
the "final delivery" of a message, it
inserts a return-path line at the
beginning of the mail data. This use
of return-path is required; mail
systems MUST support it. The
return-path line preserves the
information in the
from the MAIL command. Here, final
delivery means the message has left
the SMTP environment. Normally, this
would mean it had been delivered to
the destination user or an associated
mail drop, but in some cases it may be
further processed and transmitted by
another mail system.
and a few lines later.
A message-originating SMTP system
SHOULD NOT send a message that already
contains a Return-path header.
If you carefully read this you will understand that only the final smtp-server/delivery agent is supposed to add the Return-Path header. It is not something you as client (trying to send a mail) should do. The final smtp-server will base the Return-Path header on the sender address of the envelope (SMTP MAIL FROM part).
So setting mail.smtp.from is the correct way to tell java that the envelope sender address should be different from the from part.
If you have troubles understanding what the different from's are just take a look at a telnet smtp-session. Where replyto#example.com should correspond to mail.smtp.from and from#example.com to m.addFrom(...);
telnet smtp.example.com 25
220 smtp.example.com ESMTP .....
helo computername
250 smtp.example.com Hello computername [123.123.123.123]
mail from:<replyto#example.com>
250 <replyto#example.com> is syntactically correct
rcpt to:<rcpt#foo.com>
250 <rcpt#foo.com> verified
data
354 Enter message, ending with "." on a line by itself
To: Joey <to#joey.com>
From: Joey <from#example.com>
Subject: Joey
Hey Joey!
.
250 OK id=....
Quit
props.put("mail.smtp.from", "replyto#example.com");
Session session = Session.getDefaultInstance(props, null);
MimeMessage m = new MimeMessage(session);
m.addFrom(InternetAddress.parse("from#example.com"));

I've experienced the same issue and found the only solution discussed putting property "mail.smtp.from" props.put("mail.smtp.from", "replyto#example.com");
Still this solution was not suitable for me because I'm sending lot's of e-mails from different users, so recreating session for each e-mail would be horrible for prodictivity.
So I found another solution after reading JavaMail sources:
1) Use SMTPMessage(extends MimeMessage) instead of MimeMessage.
2) Use setEnvelopeFrom(String) method.
3) Use SMTPTransport to send e-mail (I didn't try with others).
Here is a code example:
SMTPMessage message = new SMTPMessage(session);
message.setEnvelopeFrom("returnpath#hotmail.com");
...
transport.sendMessage(message, message.getAllRecipients());

I found that if the 'mail.protocol' property is set to something other than 'smtp' (like 'smtps'), then only the following would work:
props.put("mail.smtps.from", "replyto#example.com");
This allowed me to avoid using the SMTPMessage class as described in GiorgosDev's answer (classes in the 'com.sun' package aren't intended to be public API).