Commons Email
  1. Commons Email
  2. EMAIL-55

[email] Support SMTP Envelope From (bounce address)

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: Nightly Builds
    • Fix Version/s: None
    • Labels:
      None
    • Environment:

      Operating System: other
      Platform: Other

      Description

      A patch providing "bounce address" support for Email.java, as discussed in the msg copied below. Patch also "clones" System.properties rather than setting properties upon it directly.

      At 6:04 PM -0500 4/10/03, Quinton McCombs wrote:
      > ----Original Message----
      > From: Joe Germuska Joe@Germuska.com
      > Sent: Thursday, April 10, 2003 3:15 PM
      > To: Jakarta Commons Developers List
      > Subject: [email] email bounce address?
      >
      >
      > I'm interested in porting some of my email projects to use the
      > commons-email package. However, there is one thing I'm accustomed to
      > using that isn't supported.
      >
      > Sometimes my system needs to send an email from a certain user, but
      > if the message bounces, I need the bounce to go to another address
      > instead of to the sender. It turns out that the way to do this is to
      > set the "mail.smtp.from" property in the Session object before
      > sending a message.
      >
      > It looks like adding this would be no big deal, since a new Session
      > is created every time a message is sent. So if people support
      > adding this functionality, it would be as simple as defining another
      > property on the Email object (like "bounceAddress"), and then if that
      > property isn't null, to set "mail.smtp.from" in the properties used
      > to create a new session in getMailSession().
      >
      > Looking at that code, I suppose that one might just set this value as
      > a system property, but especially since the mechanism is kind of
      > obscure, it might make the code easier for people to use if it were
      > more explicit. Also, it seems kind of transient and
      > more-appropriately set per-message than globally in the System
      > properties.
      >
      > Which brings up just one other thing: in getMailSession(), there are
      > calls to System.setProperty(). This makes me a little uncomfortable;
      > is there any reason not to make a new Properties based off of
      > System.getProperties, and then to set the values on a more transient
      > object?
      >
      > Opinions?

      All of this sounds good to me.

        Activity

        Transition Time In Source Status Execution Times Last Executer Last Execution Date
        Resolved Resolved Closed Closed
        2751d 20h 27m 1 Siegfried Goeschl 23/Oct/10 23:19
        Siegfried Goeschl made changes -
        Status Resolved [ 5 ] Closed [ 6 ]
        Henri Yandell made changes -
        Affects Version/s Nightly Builds [ 12311788 ]
        Henri Yandell made changes -
        Assignee Jakarta Commons Developers Mailing List [ commons-dev@jakarta.apache.org ]
        Project Commons [ 12310458 ] Commons Email [ 12310474 ]
        Key COM-508 EMAIL-55
        Component/s Email [ 12311114 ]
        Affects Version/s Nightly Builds [ 12311648 ]
        Henri Yandell made changes -
        Field Original Value New Value
        issue.field.bugzillaimportkey 18968 12340659
        Hide
        David Eric Pugh added a comment -

        Joe added docs.

        Show
        David Eric Pugh added a comment - Joe added docs.
        Hide
        David Eric Pugh added a comment -

        Joe,

        I am happy to have you apply this fix, I think I understand better. The one
        thing I would ask is that you put a bit of documentation into either the
        javadocs, or even better, into /xdocs describing this behavior.

        I agree that is shouldn't be a system property. System properties often have a
        habit of causing nasty head scratching bugs as you wonder why the bounce isn't
        working properly!

        Since we are moving to promote from commons-sandbox, are you also a commons
        committer? Can I list you on the STATUS document?

        Show
        David Eric Pugh added a comment - Joe, I am happy to have you apply this fix, I think I understand better. The one thing I would ask is that you put a bit of documentation into either the javadocs, or even better, into /xdocs describing this behavior. I agree that is shouldn't be a system property. System properties often have a habit of causing nasty head scratching bugs as you wonder why the bounce isn't working properly! Since we are moving to promote from commons-sandbox, are you also a commons committer? Can I list you on the STATUS document?
        Hide
        Joe Germuska added a comment -

        Sorry, Eric: I missed your recent question on this, and forgot that I had
        entered this bug when I got commons-email sandbox karma. I could apply this
        patch myself, but it seems only polite to finish discussing it since you raised
        some questions.

        Setting the "mail.smtp.from" property does make that the "default" sender, but a
        "clueless user" who called setFrom(...) would successfully change the "From" as
        it appears in the email headers. That is, the message would look like it was
        from whom you set it to be from. It would not look like it was from the
        "mail.smtp.from" value unless setFrom(...) was never called.

        However, when SMTP servers bounce mail, they do not pay attention to the "From:"
        header; they only pay attention to the "envelope" address, which can only be set
        using the "mail.smtp.from" header. This is the value set via the SMTP "MAIL
        FROM: " , which JavaMail sets using the "mail.smtp.from" property when it is
        defined.

        In short, the only way to control where undeliverable email will go, if you
        don't want it to go to the address listed in the "from" line, is by setting the
        "mail.smtp.from" property.

        Hope this clarifies things. Let me know if you want me to apply the patch, or
        if you want to apply it, or if you still don't think it should be applied.

        Show
        Joe Germuska added a comment - Sorry, Eric: I missed your recent question on this, and forgot that I had entered this bug when I got commons-email sandbox karma. I could apply this patch myself, but it seems only polite to finish discussing it since you raised some questions. Setting the "mail.smtp.from" property does make that the "default" sender, but a "clueless user" who called setFrom(...) would successfully change the "From" as it appears in the email headers. That is, the message would look like it was from whom you set it to be from. It would not look like it was from the "mail.smtp.from" value unless setFrom(...) was never called. However, when SMTP servers bounce mail, they do not pay attention to the "From:" header; they only pay attention to the "envelope" address, which can only be set using the "mail.smtp.from" header. This is the value set via the SMTP "MAIL FROM: " , which JavaMail sets using the "mail.smtp.from" property when it is defined. In short, the only way to control where undeliverable email will go, if you don't want it to go to the address listed in the "from" line, is by setting the "mail.smtp.from" property. Hope this clarifies things. Let me know if you want me to apply the patch, or if you want to apply it, or if you still don't think it should be applied.
        Hide
        David Eric Pugh added a comment -

        This is getting pretty old, let's close for now.

        Show
        David Eric Pugh added a comment - This is getting pretty old, let's close for now.
        Hide
        David Eric Pugh added a comment -

        Hi, I applied the properties clone. However, the bounce address seems a bit
        weird to me.. Basically, if I set both (being a clueless user) I would expect
        the email to be from me@myemail.com and bounce to bounce@myemail.com. However,
        in reality, it will just be from "bounce@myemail.com".

        It seems like this little bit of magic could be ansered in an FAQ entry more
        directly? What about use of the reply-to header? Would that work? Just
        looking for a more compelling use case!

        Show
        David Eric Pugh added a comment - Hi, I applied the properties clone. However, the bounce address seems a bit weird to me.. Basically, if I set both (being a clueless user) I would expect the email to be from me@myemail.com and bounce to bounce@myemail.com. However, in reality, it will just be from "bounce@myemail.com". It seems like this little bit of magic could be ansered in an FAQ entry more directly? What about use of the reply-to header? Would that work? Just looking for a more compelling use case!
        Hide
        Joe Germuska added a comment -

        Created an attachment (id=5807)
        patch supporting bounce address and properties cloning

        Show
        Joe Germuska added a comment - Created an attachment (id=5807) patch supporting bounce address and properties cloning
        Joe Germuska created issue -

          People

          • Assignee:
            Unassigned
            Reporter:
            Joe Germuska
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development