3 Replies Latest reply on Apr 9, 2004 11:27 AM by Andrew Oliver

    DomainGroup

    Tom Elrod Master

      The below is just my gut feeling, and I could be very wrong! What do you think is best.

      I think the most important thing right now is:

      1) Get the bounced message sent to the sender with the original subject and a list of the failed email addresses in the message body.

      Nice haves (which I think should be in place in a full release) would be:
      2) Include the reason for the failure, i.e. the stuff you mention below

      3) The original message attached to the bounce mail

      I think we can leave 3) for now... If you like we can split 1) and 2) between us, or you can have it all and I can do something else.

      Regarding 1) I thought the format should be to send a message with an 'empty' From header to the address in the From header of the original mail, probably with a subject (so that the sender knows which email we are talking about along with the address(es) that failed. As far as I can tell this empty From header is defined by (I think it was) RFC 2821 and RFC 1123. I might remember wrong though, as looking at a few bounced emails in my inbox I have seen the headers look like:

      From: postmaster@mail.hotmail.com
      Subject: Delivery Status Notification (Failure)
      Return-Path: <>
      <rest of headers here>

      AND
      From: CompuServe Postmaster <postmaster@compuserve.com>
      Subject: Undeliverable Message
      Return-Path: postmaster@compuserve.com
      <rest of headers here>

      AND
      Return-Path:
      Subject: Undeliverable:From dev to receivers
      From: "System Administrator" <postmaster@exhibitormanual.com>
      <rest of headers here>

      AND
      From: Systemadministrator <postmaster@softwareag.com>
      Subject: Unzustellbar: RE: Software AG Receipt Acknowledgement for Return-Path: <>
      <rest of headers here>

      They all have the From header set, but most have the Return-Path header empty, so not sure what is correct. Whoever does 1) will need to look at this in the specs to make sure we do the right thing.

      KIab

        • 1. Re: DomainGroup
          Andrew Oliver Master

          You can turn require-auth off in jboss-service.xml. However then you'd be operating as an open relay and spammers would use you. This restriction is ONLY for UN-authenticated users. Meaning if I connect to your mail server, I can send YOU a mail regardless. I can't send president@whitehouse.gov a mail using YOUR mail server.

          • 2. Re: DomainGroup
            Tom Elrod Master

            When put in entries for domain, can only send from or to that domain. So, for example, put in e2.net as domain. Can send from e2.net and receive the e-mail. Can sent to e2.net, but instead of getting to e2.net, shows up in my inbox. If try to sent from domain not listed within domain element, get:

            The e-mail account does not exist at the organization this message
            was sent to. Check the e-mail address, or contact the recipient
            directly to find out the correct address.
            < iss05.interliant.com #5.1.1 SMTP; 550 Not Authorized>

            • 3. Re: DomainGroup
              Andrew Oliver Master

              This was my bad. the dev-deploy target on the build.xml wasn't including the remote-delivery mdb's jboss.xml descriptor. You can just copy jboss-mail/src/ejb/remotedeliverymdb-jboss.xml to $JBOSS_HOME/server/default/deploy/mail.ear/remotedeliverymdb.jar/META-INF and then touch applciation.xml. BTW, sorry for spamming you with a hundred test messages :-) Anyone using the regular deploy target shouldn't have been affected by this build bug.