It means that the receiving server does not recognise the mailbox (the part before the '@') of the e-mail address. It could be that it was misspelled, that it is simply a non-existing name, or it could even be that the receiving server was set to reject a message (e.g. spam) by replying with code 550.

Here is one of many pages that summarises the SMTP reply codes, and gives links to various relevant RFCs:

EDIT: I need a bit more space to answer your question than the comments allow.

@RaghuKing, if you look at the Javadoc for javax.mail.SendFailedException, you will notice that you can call 3 methods on such an exception object (inside the catch block):

  • getInvalidAddresses() to get an array of addresses that are invalid and thus not sent to,
  • getValidSentAddresses() to get an array of addresses to which this message was sent succesfully, and
  • getValidUnsentAddresses() to get an array of addresses that are valid but to which the message was not sent to.

(Obviously, if one sends a message to multiple recipients, some may succeed and some fail, but the exception is thrown if there is at least one failure, regardless of how many successes. Obviously also if you are sending to only one address, you will have that one address in only one of these arrays, and it will probably NOT be in the ValidSent list.

These arrays will give you more information how to handle the exception, depending of the type of array an address is in. This will obviously depend on you application, but these might be reasonable suggestions:

  • Invalid Addresses: tell the user that the message was not sent because the address was wrong, for each invalid address in the list, and provide a way to correct the address, then try to resend to the correct address (or cancel if the user does not provide a different address);
  • Valid Sent Addresses: Don't resend;
  • Valid Unsent Addresses: Try to resend to these addresses. Sending probably stopped before getting to these addresses because of a previous incorrect address.

But in the end it is you who has to apply common sense, and perhaps experiment a little with the functions you don't understand until you understand them.

source -

저작자 표시

'Development > Java' 카테고리의 다른 글

javamail - SendFailedException  (0) 2017.04.06
javamail - SMTP BCC  (0) 2017.03.31
java - NIO Selector and epoll  (0) 2017.03.17
java - Architecture of a Highly Scalable NIO-Based Server  (0) 2017.03.17
java - Understanding JUnit's Runner architecture  (0) 2016.07.24
java8 - Metaspace  (0) 2016.02.27
Posted by linuxism

How to use session in jsp pages to get information?

JSP implicit objects likes sessionrequest etc. are not available inside JSP declaration <%! %> tags.

You could use it directly in your expression as

<td>Username: </td>
<td><input type="text" value="<%= session.getAttribute("username") %>" /></td>

On other note, using scriptlets in JSP has been long deprecated. Use of EL (expression language) and JSTL tags is highly recommended. For example, here you could use EL as

<td>Username: </td>
<td><input type="text" value="${username}" /></td>

The best part is that scope resolution is done automatically. So, here username could come from page, or request, or session, or application scopes in that order. If for a particular instance you need to override this because of a name collision you can explicitly specify the scope as

<td><input type="text" value="${requestScope.username}" /></td> or,
<td><input type="text" value="${sessionScope.username}" /></td> or,
<td><input type="text" value="${applicationScope.username}" /></td>

source -

저작자 표시

'Development > JSP & Servlet' 카테고리의 다른 글

jsp - SessionScope  (0) 2017.04.04
jsp - difference between eq and ==  (0) 2017.02.03
jsp - 컴파일(compile)  (0) 2016.05.13
jsp - jstl fn:contains  (0) 2014.07.10
servlet - 3.0 비동기 기능  (0) 2013.07.27
servlet - 필터(filter)  (0) 2013.07.27
Posted by linuxism

Blind carbon copy allows the sender of a message to conceal the person entered in the BCC field from the other recipients. This concept originally applied to paper correspondence (carbon copy) and now also applies to e-mails.[1]

In some circumstances, the typist creating a paper correspondence must ensure that multiple recipients of such a document do not see the names of other recipients. To achieve this, the typist can:

  • Add the names in a second step to each copy, without carbon paper;
  • Set the ribbon not to strike the paper, which leaves names off the top copy (but may leave letter impressions on the paper).

With email, recipients of a message are specified using addresses in any of these three fields:

  • To: primary recipients
  • CCcarbon copy to secondary recipients (other interested parties)
  • BCC: blind carbon copy to tertiary recipients who receive the message. The primary and secondary recipients cannot see the tertiary recipients. Depending on email software, the tertiary recipients may only see their own email address in BCC, or they may see the email addresses of all primary and secondary recipients.

It is common practice to use the BCC field when addressing a very long list of recipients, or a list of recipients that should not (necessarily) know each other, e.g. in mailing lists.[2]

Benefits[edit source]

There are a number of reasons for using this feature:

  • BCC is often used to prevent an accidental "Reply all" from sending a reply intended for only the originator of the message to the entire recipient list.[3]
  • To send a copy of one's correspondence to a third party (for example, a colleague) when one does not want to let the recipient know that this is being done (or when one does not want the recipient to know the third party's e-mail address, assuming the other recipient is in the To or CC fields).
  • To send a message to multiple parties with none of them knowing the other recipients. This can be accomplished by addressing a message to oneself and filling in the actual intended recipients in the BCC field.
  • To prevent the spread of computer virusesspam, and malware by avoiding the accumulation of block-list e-mail addresses available to all BCC recipients, which often occurs in the form of chain letters.

Disadvantages[edit source]

In some cases, use of blind carbon copy may be viewed as mildly unethical. The original addressee of the mail (To: address) is left under the impression that communication is proceeding between the known parties, and is knowingly kept unaware of others participating in the primary communication.

A related risk is that by (unintentional) use of 'reply to all' functionality by someone on BCC, the original addressee is (inadvertently) made aware of this participation. For this reason, it is in some cases better to separately forward the original e-mail.

Depending on the particular email software used, the recipient may or may not know that the message has been sent via BCC. In some cases, ‘undisclosed recipients’ placed in the To: line (by the software) shows that BCC has been used.[citation needed] In other cases, the message appears identical to one sent to a single addressee.[citation needed] The recipient does not necessarily see the email address (and real name, if any) originally placed in the To: line.

When it is useful for the recipients to know who else has received a BCC message,

  • their real names, but not their email addresses, can be listed in the body of the message, or
  • a meaningful substitute for the names can be placed in the body of the message, e.g. ‘[To General Manager and members of Remunerations Committee]’, or ‘[To the whole Bloggs family]’.

Carbon vs. courtesy[edit source]

The interpretation of "BCC" as "blind courtesy copy" is a backronym and not the original meaning; the historic RFC 733 has an explicit "blind carbon" annotation in its definition of the BCC header field syntax. "CC" and "BCC" mean "carbon copy" and "blind carbon copy" respectively.

Sending courtesy copies of mailing list replies also directly to the author(s) of answered message(s) is a common practice on some lists[citation needed], and matches a new interpretation of "CC" as abbreviation for "courtesy copy".[dubious ]

References[edit source]

  1. Jump up^ Stout, Chris. "DEAR NERD: Blind carbons hide addresses." Charleston Gazette (West Virgiㅏnia, USA). 1998-01-18. page P5B. NewsBank record number 100F35638A890441.
  2. Jump up^ Husted, Bill. "Bad e-mail habits can be bothersome, embarrassing" Atlanta Journal-Constitution, The (Georgia, USA). 2009-08-30. page E15. NewsBank record number 103419444.
  3. Jump up^ Boodhoo, Niala; Carey, Bridget (2009-08-25). "Be careful when you 'reply all' to e-mail". Miami Herald. pp. C8. NewsBank record number 200908250100KNRIDDERFLMIAMIH_poked-08-25-09.

External links[edit source]

source -

The BCC addresses are not stripped off at the destination email server. That's not how it works.

How SMTP actually works

  • The sender will send a list of RCPT TO commands to the SMTP server, one for each receiver email addresses, and this command does not distinguish whether the receiver is a normal To, CC or BCC type receiver.
  • Soon enough after calling the command that tells the SMTP server who's the sender, who's the server, and everything else, only then the sender will call the DATA command, in which will contain the content of the email - which consist of the email headers and body - the one that are received by email clients. Among these email headers are the usual from address, to address, CC address.
  • The BCC address is not shown to the receiver, simply because it's not printed out under the DATA command, not because the destination SMTP server stripped them away. The destination SMTP server will just refer to the RCPT TO for the list of email addresses that should receive the email content. It does not really care whether the receiver is in the To, CC or BCC list.
    Update (to clarify): BCC email addresses must be listed in the RCPT TO command list, but the BCC header should not be printed under the DATA command.

Quoting a part of the RFC that I think is relevant to your case:

Please note that the mail data includes the memo header items such as Date, Subject, To, Cc, From [2].

Rolling out your own email sender

A couple of years ago, I frankly think, is quite a long time back to assume that you still memorize end-to-end of RFC 821. :)

source -

저작자 표시

'Development > Java' 카테고리의 다른 글

javamail - SendFailedException  (0) 2017.04.06
javamail - SMTP BCC  (0) 2017.03.31
java - NIO Selector and epoll  (0) 2017.03.17
java - Architecture of a Highly Scalable NIO-Based Server  (0) 2017.03.17
java - Understanding JUnit's Runner architecture  (0) 2016.07.24
java8 - Metaspace  (0) 2016.02.27
Posted by linuxism

티스토리 툴바