e-m4i1 from filepro with attachment

Thu Jun 29 05:14:15 PDT 2006

On Wed, Jun 28, 2006 at 02:04:13PM -0400, John Esak, the prominent pundit,
witicized:
> I think it is a little cheap at $99... $150 should be the price... $149.

I'll take that under advisement, John. :) I mean, seriously, I'm thinking
about it.  I don't see any reason not to.  I've tried competing on price
before (OneGate)...it doesn't work.  My only worry is that someone may
think it's -already- overpriced.  All here who think software these days
isn't overpriced, raise your hands.  Yeah, thought so. :) So do I.  But it
-is- powerful mojo that can be used at the enterprise level, so yes, I may
soon raise the price at your suggestion.  Possibly next week.  I'm
considering my options for a few days.  Rash decisions usually end up
poorly for me.  :)

Actually, someone recommended sendEmail as a free alternative.  So I just
-had- to look at what I was up against, of course.  I just went over the
docs -and- the source.  I'm frightened. :) No, seriously...in an effort NOT
to use any existing, known-good modules, he basically reimplemented a basic
SMTP conversation and rudimentary MIME formatting.  It didn't look like a
very robust implementation of either, to me.

There were also several things missing that I handle with LightMail, such
as inline image attachments (the images display inline in the message),
utilising a local MTA if one is present (I can do that in addition to just
using an SMTP server elsewhere), -unlimited- custom headers (he provides
a whopping -one-), and HTML-only message bodies ONLY when specified, not
taking the MS approach and doing it if it sees "<html>" (which may or may
not even APPEAR in some HTML, depending what generated it)...  That's
seriously how he tells whether he should be sending as pure html or not.
His MIME encoding is crude compared to what the modules I used avail me
of.  I'd expect that; he rolled the -entire- thing by hand, reinventing the
wheels for SMTP and MIME in a -very- minimalistic sense.

About the only thing his does that mine doesn't is SASL authentication.  I
could add that in under an hour, beta test, and have it out the door in
under two if I -really- needed to.  In fact, it -almost- went in at one
point, but it turned out not to be needed for a potential customer after
all, so I didn't waste the time rerouting the transport to a manually
controlled object just to accomodate it.  Ah, and his will take the main
message file from STDIN--on unix only.  I had a reason for avoiding
that--namely I never wanted it to infinitely hang if nothing was fed to
STDIN and no file location was defined.  His code comments flat-out say
that his methodology for using alarm doesn't work in Win32.  I didn't want
something that wouldn't work 100% cross-platform.

Then there's the part where sending attachments that are large may not
actually work with his alarm system.  This is hilarious if you read his
comments:

        ## Disable the alarm so people on modems can send big attachments
        alarm(0) if ($^O !~ /win/i);  ## alarm() doesn't work in win32

Okay, so if you're on Win32, you're what, potentially boned if you want to
send big attachments via modem?  Great idea!

I won't get into his assumption about hardwired colour escape sequences for
echoing things to the console--assuming there's only going to be one
terminal type.  Oh, wait, I just did.  :)

I've seen far worse, but I wasn't impressed.  If I was me, <scrooged>And I
-AM-! *plink!*</scrooged>, I'd take LightMail over sendEmail any day, cost
notwithstanding.

Not really wanting to -bash- other software, but since someone else brought
it up, I figured I'd take a look and do a comparative analysis of the
"competition".  There were a lot of shortcomings there.  After seeing it,
I can say that the two are conceived like apples and oranges.  They're
both fruit, but there's a fundamental design difference.  Kudos to the
author on his achievements, and I wish him the best of luck, but I wouldn't
personally trust it, having read the source.  YMMV.

mark->