Re: SMTP Log?

[Scott Klement <midrange-l@xxxxxxxxxxxxxxxx>]

How are you creating these e-mails?

One of the most common (and aggravating) things about this system is the 
horrible QtmmSendMail() API that folks seem to insist on using for their 
mail tools.   To use this API, you create an IFS stream file containing 
the message, then call the API and tell it about the recipients of the 
message and what the stream file is called.  The API then hands it off 
to the batch jobs that handle mail to do the processing.

The problem is...  if your program proceeds to reuse that same stream 
file, it has an excellent chance of changing it before the batch job 
gets ahold of it.

You write an e-mail to customer A (let's say A="Alice").  You create a 
stream file containing the relevant details of Alice's account status 
with you.  You now call QtmmSendMail and tell it that this stream file 
is to be sent to Alice.  After you're done, you replace the stream file 
with details for Bob (Customer B=Bob)...   But the batch job that 
handles e-mail is working at the same time, and it's sending that stream 
file to Alice...   due to the timing, you may change the stream file as 
it's being sent to Alice -- and therefore Alice gets Bob's data. 
Meanwhile your program continues, and cues up an E-mail to go to Bob... 
  Now the batch job starts to process it, but your program has now 
changed the stream file to be for Charlie...  so Charlie gets Bob's 
data...  all depending on whether your program runs faster or the 
background e-mail software runs faster.

Personally, I don't use the QtmmSendMail() API.  It's not easy to use. 
It's not easy to troubleshoot, and it doesn't notify you when it's done 
with your stream file.

Instead, I use sockets to talk directly to the SMTP server.  It's not 
really any harder (indeed, once you've turned your SMTP program into a 
reusable service program, it's considerably easier, because 
QtmmSendMail() has such a crappy interface.)   Talking SMTP directly, 
the background server has no knowledge of your file on disk... it just 
knows what you've sent over the socket.  Once you get a response code 
from it, you know it accepted your message.

Plus, you have the option to connect to any SMTP server (not just the 
one IBM provides with i)

And it's much easier to troubleshoot, because you've coded better error 
logging and tracing into your application.  Vs. IBM's messages like 
"Something in a parameter is invalid." leaving you to guess what the 
problem was...  or even worse, the fact that if the server decides not 
to relay your message, you don't find out at all unless you check the 
logs or have a bounce account that it's sent to.


On 4/1/2010 1:04 PM, Mike wrote:
> It happened again! This time we were sending out AP payment notices and some
> customers received other customers' water bills or invoices from AR. From
> 9/09 in both cases. Is there a queue somewhere that may hold these emails
> that could get cleared out?
>
> --
> Mike Wills
> http://mikewills.info
> P: (507) 933-0880 | Skype: koldark
>
>
> On Wed, Mar 31, 2010 at 10:06 AM, Mike<koldark@xxxxxxxxx>  wrote:
>
> > The utility bill doesn't even have any attachments. The AR invoice does,
> > but the utility bill points the customer to our website for details.
> >
> > --
> > Mike Wills
> > http://mikewills.info
> > P: (507) 933-0880 | Skype: koldark
> >
> >
> > On Wed, Mar 31, 2010 at 9:41 AM,<rob@xxxxxxxxx>  wrote:
> >
> > > Keep an eye on it.
> > >
> > > I've found that a bulk emailing with attachments should be done at it's
> > > own time.  It was a real hoot when paystubs went to the wrong people. Hey,
> > > we've now outsourced payroll, direct deposit is mandatory, and if you want
> > > to look at your stub go to their website.
> > >
> > >
> > > Rob Berendt
> > > --
> > > Group Dekko Services, LLC
> > > Dept 01.073
> > > Dock 108
> > > 6928N 400E
> > > Kendallville, IN 46755
> > > http://www.dekko.com
> > >
> > >
> > >
> > >
> > >
> > > From:   Mike<koldark@xxxxxxxxx>
> > > To:     Midrange Systems Technical Discussion<midrange-l@xxxxxxxxxxxx>
> > > Date:   03/31/2010 10:01 AM
> > > Subject:        Re: SMTP Log?
> > > Sent by:        midrange-l-bounces@xxxxxxxxxxxx
> > >
> > >
> > >
> > > Thanks guys for the tips. I couldn't find anything. We are going to call
> > > it
> > > a glitch until it happens again. Everything about it is just weird.
> > >
> > > --
> > > Mike Wills
> > > http://mikewills.info
> > > P: (507) 933-0880 | Skype: koldark
> > >
> > >
> > > On Tue, Mar 30, 2010 at 10:56 AM, James Perkins
> > > <jrperkinsjr@xxxxxxxxx>wrote:
> > >
> > > > If you have journaling turned on it is journaled in the QZMF journal.
> > > > Try DSPJRN QZMF.
> > > > --
> > > > James R. Perkins
> > > >
> > > >
> > > >
> > > > On Tue, Mar 30, 2010 at 07:54, Mike<koldark@xxxxxxxxx>  wrote:
> > > > > Is there any logs created by the SMTP server? I am tracking down a
> > > > mailing
> > > > > issue and am having a heck of a time figuring out the source of the
> > > > problem.
> > > > > Saturday morning we had 4 customer emails go out from our AR system
> > > > (which
> > > > > is on generated at the time they print invoices) when no one was in
> > > the
> > > > > building. The only thing that got sent out that day was from an
> > > automatic
> > > > > job that emails out our water bills (different system from AR). The
> > > > > "original" invoice email was send in August of last year. It was
> > > emailed
> > > > out
> > > > > again on Saturday to a different person. For example, the original was
> > > > sent
> > > > > to ar@xxxxxxxxxxx, CCed: ar@xxxxxxxxxxxxx, and at one point BCCed
> > > > > me@xxxxxxxxxxxxx so I could monitor the emails to make sure they were
> > > > > sending okay. On Saturday, the same email sent out to
> > > customer@xxxxxxxxxxxx
> > > > > BCCed me@xxxxxxxxxxxxxx The copy of my email had it marked as sent on
> > > > Aug.
> > > > > '09 was TO: ar@xxxxxxxxxxxx I am going to check the headers of the
> > > > replies
> > > > > to see what I can see in those yet.
> > > > >
> > > > > Have you seen that before?
> > > > >
> > > > > --
> > > > > Mike Wills
> > > > > http://mikewills.info
> > > > > P: (507) 933-0880 | Skype: koldark
> > > > > --
> > > > > This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
> > > > list
> > > > > To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> > > > > To subscribe, unsubscribe, or change list options,
> > > > > visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> > > > > or email: MIDRANGE-L-request@xxxxxxxxxxxx
> > > > > Before posting, please take a moment to review the archives
> > > > > at http://archive.midrange.com/midrange-l.
> > > > --
> > > > This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
> > > list
> > > > To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> > > > To subscribe, unsubscribe, or change list options,
> > > > visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> > > > or email: MIDRANGE-L-request@xxxxxxxxxxxx
> > > > Before posting, please take a moment to review the archives
> > > > at http://archive.midrange.com/midrange-l.
> > > --
> > > This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
> > > list
> > > To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> > > To subscribe, unsubscribe, or change list options,
> > > visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> > > or email: MIDRANGE-L-request@xxxxxxxxxxxx
> > > Before posting, please take a moment to review the archives
> > > at http://archive.midrange.com/midrange-l.
> > >
> > >
> > > --
> > > This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
> > > list
> > > To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> > > To subscribe, unsubscribe, or change list options,
> > > visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> > > or email: MIDRANGE-L-request@xxxxxxxxxxxx
> > > Before posting, please take a moment to review the archives
> > > at http://archive.midrange.com/midrange-l.