Perl, Mail, Mime & Multipart....

Discussion in 'Perl Misc' started by amerar@iwc.net, Jun 3, 2005.

  1. Guest

    Hi,

    I have a Perl script which sends out emails for us. I want to change
    it such that it sends out both a text portion and an HTML portion.

    >From what I have read, with a multipart/mixed header and the proper

    boundary tagbs, the email client will decide which is the best to
    display.

    I have pasted my code below. I am testing with Netscape Messenger.
    And, no matter what, it always displays both text & html.

    Maybe someone can see if I've made some errors or something....

    Thanks in advance.

    $smtp->datasend("From: $from1\n");
    $smtp->datasend("Reply-To: $replyto\n");
    $smtp->datasend("To: $email\n");
    $smtp->datasend("Subject: $subject\n");
    $smtp->datasend("Mime-Version: 1.0\n");
    $smtp->datasend("Content-Type: multipart/mixed;\n");
    $smtp->datasend(" boundary=\"theBoundary\"\n\n");
    $smtp->datasend("\n\n");
    $smtp->datasend("--theBoundary\n");
    $smtp->datasend("Content-Type: text/plain; charset=us-ascii\n\n");
    foreach $line (@text_letter) {
    $smtp->datasend("$line\n");
    }
    $smtp->datasend("\n\n");
    $smtp->datasend("--theBoundary\n");
    $smtp->datasend("Content-Type: text/html; charset=us-ascii\n\n");
    foreach $line (@html_letter) {
    $smtp->datasend("$line\n");
    }
    $smtp->datasend("\n--theBoundary--\n");

    Arthur
     
    , Jun 3, 2005
    #1
    1. Advertising

  2. wrote in news::

    > I have a Perl script which sends out emails for us. I want to change
    > it such that it sends out both a text portion and an HTML portion.
    >
    >>From what I have read, with a multipart/mixed header and the proper

    > boundary tagbs, the email client will decide which is the best to
    > display.
    >
    > I have pasted my code below.


    <URL: http://search.cpan.org/~yves/MIME-Lite-3.01/lib/MIME/Lite.pm#Create_a_multipart_message>

    Sinan

    --
    A. Sinan Unur <>
    (reverse each component and remove .invalid for email address)

    comp.lang.perl.misc guidelines on the WWW:
    http://mail.augustmail.com/~tadmc/clpmisc/clpmisc_guidelines.html
     
    A. Sinan Unur, Jun 4, 2005
    #2
    1. Advertising

  3. wrote:
    > Hi,
    >
    > I have a Perl script which sends out emails for us. I want to change
    > it such that it sends out both a text portion and an HTML portion.
    >
    >>From what I have read, with a multipart/mixed header and the proper

    > boundary tagbs, the email client will decide which is the best to
    > display.
    >
    > I have pasted my code below. I am testing with Netscape Messenger.
    > And, no matter what, it always displays both text & html.
    >
    > Maybe someone can see if I've made some errors or something....
    >


    Perhaps you need multipart/alternative rather than multipart/mixed.
     
    RedGrittyBrick, Jun 4, 2005
    #3
  4. wrote:

    > I have a Perl script which sends out emails for us. I want to change
    > it such that it sends out both a text portion and an HTML portion.
    >
    >>From what I have read, with a multipart/mixed header and the proper

    > boundary tagbs, the email client will decide which is the best to
    > display.


    I'm fairly lazy (hey, it's supposed to be a virtue for a programmer), so
    I took the following approach. I took the source for a sample mail I
    created in Thunderbird (any mail app will do), stripped out the contents
    and replaced it with $variable names. Pasted the result in my script
    (under the __DATA__ line).

    The script reads in the mail template from the <DATA> handler, calls
    eval() to substitute the variables and sends the mail out with Net::SMTP.

    Ximinez
    --
    Our three weapons are fear, surprise, and ruthless efficiency...
    and an almost fanatical devotion to the Pope....
    http://www.ai.mit.edu/people/paulfitz/spanish/t1.html
     
    The Spanish Inquisition, Jun 5, 2005
    #4
  5. John Bokma Guest

    The Spanish Inquisition wrote:

    > wrote:
    >
    >> I have a Perl script which sends out emails for us. I want to change
    >> it such that it sends out both a text portion and an HTML portion.
    >>
    >>>From what I have read, with a multipart/mixed header and the proper

    >> boundary tagbs, the email client will decide which is the best to
    >> display.

    >
    > I'm fairly lazy (hey, it's supposed to be a virtue for a programmer), so
    > I took the following approach.


    That's not lazy... Lazy is going to CPAN and then use the right module for
    the job. So you don't have to worry about all those details, testing, etc.

    --
    John Small Perl scripts: http://johnbokma.com/perl/
    Perl programmer available: http://castleamber.com/
    Happy Customers: http://castleamber.com/testimonials.html
     
    John Bokma, Jun 5, 2005
    #5
  6. John Bokma wrote:
    > The Spanish Inquisition wrote:
    >
    >
    >> wrote:
    >>
    >>
    >>>I have a Perl script which sends out emails for us. I want to change
    >>>it such that it sends out both a text portion and an HTML portion.
    >>>
    >>>>From what I have read, with a multipart/mixed header and the proper
    >>>boundary tagbs, the email client will decide which is the best to
    >>>display.

    >>
    >>I'm fairly lazy (hey, it's supposed to be a virtue for a programmer), so
    >>I took the following approach.

    >
    > That's not lazy... Lazy is going to CPAN and then use the right module for
    > the job. So you don't have to worry about all those details, testing, etc.


    These modules are complicated enough to require testing. Detailed enough
    to require tinkering and tiring activities like documentation reading
    (brrr). I just let Thunderbird do all the work for me and copy&pasted a
    little.

    And then there are CPAN modules that simply refuse to install without
    errors, or 'force' install with some errors, so you're never quite sure
    whether they'll run correctly or not.

    I remember that time when I tried to move a script that used POE to a
    different machine. Unfortunately POE wouldn't install on the new system
    for some obscure reason. There goes portability...

    CPAN modules are great for many reasons, but if there's an easy way to
    do it without another module dependency I'll take it.

    Ximinez
    --
    Our three weapons are fear, surprise, and ruthless efficiency...
    and an almost fanatical devotion to the Pope....
    http://www.ai.mit.edu/people/paulfitz/spanish/t1.html
     
    The Spanish Inquisition, Jun 6, 2005
    #6
  7. John Bokma Guest

    The Spanish Inquisition wrote:

    > John Bokma wrote:
    >> The Spanish Inquisition wrote:
    >>
    >>
    >>> wrote:
    >>>
    >>>
    >>>>I have a Perl script which sends out emails for us. I want to
    >>>>change it such that it sends out both a text portion and an HTML
    >>>>portion.
    >>>>
    >>>>>From what I have read, with a multipart/mixed header and the proper
    >>>>boundary tagbs, the email client will decide which is the best to
    >>>>display.
    >>>
    >>>I'm fairly lazy (hey, it's supposed to be a virtue for a programmer),
    >>>so I took the following approach.

    >>
    >> That's not lazy... Lazy is going to CPAN and then use the right
    >> module for the job. So you don't have to worry about all those
    >> details, testing, etc.

    >
    > These modules are complicated enough to require testing. Detailed
    > enough to require tinkering and tiring activities like documentation
    > reading (brrr).


    Have you ever used MIME::Lite?

    > I remember that time when I tried to move a script that used POE to a
    > different machine. Unfortunately POE wouldn't install on the new
    > system for some obscure reason. There goes portability...


    But is that CPAN/POE/Perl or the "other machine".

    > CPAN modules are great for many reasons, but if there's an easy way to
    > do it without another module dependency I'll take it.


    Reinventing the wheel by cutting off 4 corners of a rock is not the easy
    way.

    --
    John Small Perl scripts: http://johnbokma.com/perl/
    Perl programmer available: http://castleamber.com/
    Happy Customers: http://castleamber.com/testimonials.html
     
    John Bokma, Jun 6, 2005
    #7
  8. John Bokma wrote:

    > The Spanish Inquisition wrote:
    >
    >>John Bokma wrote:
    >>
    >>>The Spanish Inquisition wrote:
    >>>
    >>>> wrote:
    >>>>
    >>>>>I have a Perl script which sends out emails for us. I want to
    >>>>>change it such that it sends out both a text portion and an HTML
    >>>>>portion.
    >>>>>
    >>>>>>From what I have read, with a multipart/mixed header and the proper
    >>>>>boundary tagbs, the email client will decide which is the best to
    >>>>>display.
    >>>>
    >>>>I'm fairly lazy (hey, it's supposed to be a virtue for a programmer),
    >>>>so I took the following approach.
    >>>
    >>>That's not lazy... Lazy is going to CPAN and then use the right
    >>>module for the job. So you don't have to worry about all those
    >>>details, testing, etc.

    >>
    >>These modules are complicated enough to require testing. Detailed
    >>enough to require tinkering and tiring activities like documentation
    >>reading (brrr).

    >
    > Have you ever used MIME::Lite?


    I have tried it, actually. I found the template method easier. Not only
    to avoid using the module but also because it allows me to store prefab
    message templates in files and have them filled in by the perl mailer.
    Works pretty well for my purposes.

    >>I remember that time when I tried to move a script that used POE to a
    >>different machine. Unfortunately POE wouldn't install on the new
    >>system for some obscure reason. There goes portability...

    >
    > But is that CPAN/POE/Perl or the "other machine".


    Does it matter? Not all CPAN modules are perfect. Some of them are quite
    complicated and won't compile in certain circumstances. These
    circumstances can't always be avoided.

    >>CPAN modules are great for many reasons, but if there's an easy way to
    >>do it without another module dependency I'll take it.

    >
    > Reinventing the wheel by cutting off 4 corners of a rock is not the easy
    > way.


    Cute. We're not talking wheels here, though. We're talking alternative
    solutions to creating simple mail messages. Both solutions work and both
    have their advantages. Sorry to have stumble on a dogma here...

    Ximinez
    --
    Our three weapons are fear, surprise, and ruthless efficiency...
    and an almost fanatical devotion to the Pope....
    http://www.ai.mit.edu/people/paulfitz/spanish/t1.html
     
    The Spanish Inquisition, Jun 6, 2005
    #8
  9. John Bokma Guest

    The Spanish Inquisition wrote:

    > John Bokma wrote:


    :

    >> Have you ever used MIME::Lite?

    >
    > I have tried it, actually. I found the template method easier.


    So you gave up soon, and now create code that's hard to maintain for
    others. Yes, MIME::Lite takes like 10 minutes to understand, and yes, I
    know reading doesn't look productive, but pressing all those keys the
    whole day looks like a lot is going on. But no serious programmer should
    do what you did.

    > Not
    > only to avoid using the module but also because it allows me to store
    > prefab message templates in files


    Since you haven't checked out on MIME:Lite, you missed that you can do
    this to, I guess.

    > and have them filled in by the perl
    > mailer. Works pretty well for my purposes.


    Yes, you created hard to maintain code, not a big deal if it's your
    tool, but a big deal if others have to maintain it. Moreover, you missed
    an opertunity to learn a new module, a big loss IMNSHO.

    >>>I remember that time when I tried to move a script that used POE to a
    >>>different machine. Unfortunately POE wouldn't install on the new
    >>>system for some obscure reason. There goes portability...

    >>
    >> But is that CPAN/POE/Perl or the "other machine".

    >
    > Does it matter?


    Of course it does, you rant about CPAN but the problem is very likely
    the machine. How can CPAN fix the problems on your machine?

    > Not all CPAN modules are perfect.


    Never said so. But if everbody does it your way we get a lot, and I mean
    a lot, of less than perfect code that's extremely hard to maintain, and
    full of bugs. CPAN modules are not perfect, but if everybody uses them
    they can get better. If you find a problem or have a suggestion it can
    be fixed/added.

    > Some of them are quite complicated


    If you consider a module complicated I hate to guess your Perl skills.
    Programming is complicated, period.

    > and won't compile in certain circumstances. These
    > circumstances can't always be avoided.


    But you can report them, or contribute for the free use (and huge time
    saver) the others give you, and help to fix the problem. Most modules
    are made in spare time, you can't expect everybody to have access to
    several set ups and make everything work so you can have a free ride.

    Contribute and make it grow.

    >> Reinventing the wheel by cutting off 4 corners of a rock is not the
    >> easy way.

    >
    > Cute. We're not talking wheels here, though. We're talking alternative
    > solutions to creating simple mail messages. Both solutions work and
    > both have their advantages. Sorry to have stumble on a dogma here...


    Yours has only an advantage for you, and maybe that advantage is based
    on misunderstandig since you sound like someone who measures
    productivity by the number of keystrokes/hour.

    --
    John Small Perl scripts: http://johnbokma.com/perl/
    Perl programmer available: http://castleamber.com/
    Happy Customers: http://castleamber.com/testimonials.html
     
    John Bokma, Jun 6, 2005
    #9
  10. John Bokma wrote:

    > The Spanish Inquisition wrote:
    >
    >>John Bokma wrote:

    >
    >>>Have you ever used MIME::Lite?

    >>
    >>I have tried it, actually. I found the template method easier.

    >
    > So you gave up soon, and now create code that's hard to maintain for
    > others. Yes, MIME::Lite takes like 10 minutes to understand, and yes, I
    > know reading doesn't look productive, but pressing all those keys the
    > whole day looks like a lot is going on. But no serious programmer should
    > do what you did.


    Sure, so I'm not a serious programmer. That didn't you take long to
    figure out, did it? I guess ten of thousands of satisfied users and
    mainatinable systems that run for years on years don't count. No, my
    less-than-dogmatic stance on reuse of modules dequalifies me completely.

    It takes all sorts, John. I may not be your idea of an ideal programmer,
    but I know I have some qualities that many other programmers miss. I
    know some people who are pretty glad I'm not like other programmers.

    >>Not
    >>only to avoid using the module but also because it allows me to store
    >>prefab message templates in files

    >
    > Since you haven't checked out on MIME:Lite, you missed that you can do
    > this to, I guess.


    Possibly.

    >>and have them filled in by the perl
    >>mailer. Works pretty well for my purposes.

    >
    > Yes, you created hard to maintain code, not a big deal if it's your
    > tool, but a big deal if others have to maintain it. Moreover, you missed
    > an opertunity to learn a new module, a big loss IMNSHO.


    You can't learn everything as every programmer knows...

    >>>>I remember that time when I tried to move a script that used POE to a
    >>>>different machine. Unfortunately POE wouldn't install on the new
    >>>>system for some obscure reason. There goes portability...
    >>>
    >>>But is that CPAN/POE/Perl or the "other machine".

    >>
    >>Does it matter?

    >
    > Of course it does, you rant about CPAN but the problem is very likely
    > the machine. How can CPAN fix the problems on your machine?


    I'm not saying it should. I'm saying that dependance on complicated
    modules may hurt me (and my coworkers) in certain cases. It's no-one's
    fault in particular, but it's something to consider when you have to
    choose between rolling your own and using someone else's work.

    >>Not all CPAN modules are perfect.

    >
    > Never said so. But if everbody does it your way we get a lot, and I mean
    > a lot, of less than perfect code that's extremely hard to maintain, and
    > full of bugs. CPAN modules are not perfect, but if everybody uses them
    > they can get better. If you find a problem or have a suggestion it can
    > be fixed/added.


    Agreed there, but hey, I never said I wasn't lazy.

    >>Some of them are quite complicated

    >
    > If you consider a module complicated I hate to guess your Perl skills.
    > Programming is complicated, period.


    I consider some modules complicated. POE is a good example. It good
    stuff but it depends on many other modules and I've seen it not-compile
    on some occasions. I consider other modules less complicated and some
    are downright simple.

    I've nothing against using modules in general. Hell, who could be a
    serious perl programmer without using and writing modules?

    >>and won't compile in certain circumstances. These
    >>circumstances can't always be avoided.

    >
    > But you can report them, or contribute for the free use (and huge time
    > saver) the others give you, and help to fix the problem. Most modules
    > are made in spare time, you can't expect everybody to have access to
    > several set ups and make everything work so you can have a free ride.
    >
    > Contribute and make it grow.


    Guilty as charged, I should do more of that. Unfortunately not all bug
    reports are acted on or even reacted on, which doesn't always help with
    motivation. Analysing what exactly is going wrong can be a lot of work.

    >>>Reinventing the wheel by cutting off 4 corners of a rock is not the
    >>>easy way.

    >>
    >>Cute. We're not talking wheels here, though. We're talking alternative
    >>solutions to creating simple mail messages. Both solutions work and
    >>both have their advantages. Sorry to have stumble on a dogma here...

    >
    > Yours has only an advantage for you, and maybe that advantage is based
    > on misunderstandig since you sound like someone who measures
    > productivity by the number of keystrokes/hour.


    No, not exactly. Sometimes I spend hours polishing stuff until it's just
    right and sometimes I just do it the quick way. Sometimes I reconsider
    later and do it right after all. Pretty much the way most people work, I
    guess... (but then again I'm not a real programmer eh?)

    Gee, I always liked the relaxed attitude of the Perl crowd, whatever
    happened to that?

    Ximinez
    --
    Our three weapons are fear, surprise, and ruthless efficiency...
    and an almost fanatical devotion to the Pope....
    http://www.ai.mit.edu/people/paulfitz/spanish/t1.html
     
    The Spanish Inquisition, Jun 7, 2005
    #10
  11. On Tue, 7 Jun 2005, The Spanish Inquisition wrote:

    > John Bokma wrote:
    >
    > > So you gave up soon, and now create code that's hard to maintain
    > > for others. Yes, MIME::Lite takes like 10 minutes to understand,
    > > and yes, I know reading doesn't look productive, but pressing all
    > > those keys the whole day looks like a lot is going on. But no
    > > serious programmer should do what you did.

    >
    > Sure, so I'm not a serious programmer. That didn't you take long to
    > figure out, did it? I guess ten of thousands of satisfied users and
    > mainatinable systems that run for years on years don't count. No, my
    > less-than-dogmatic stance on reuse of modules dequalifies me
    > completely.


    Your apparent unwillingness to step right up and discuss the
    substantive issues raised by John B does rather convey a message, you
    know.

    If you've been so widely active as you say, one wonders how many
    maintenance programmers are cursing your name in the meantime (or
    maybe they just tossed the code out and started again, as so often
    happens with hand-knitted code).

    > > Yes, you created hard to maintain code, not a big deal if it's
    > > your tool, but a big deal if others have to maintain it. Moreover,
    > > you missed an opertunity to learn a new module, a big loss IMNSHO.

    >
    > You can't learn everything as every programmer knows...


    No disagreement there. However, using that as an excuse for publicly
    refusing to learn more seems to me to be a sub-optimal way to proceed.
     
    Alan J. Flavell, Jun 7, 2005
    #11
  12. Alan J. Flavell wrote:

    > On Tue, 7 Jun 2005, The Spanish Inquisition wrote:
    >
    >>John Bokma wrote:
    >>
    >>>So you gave up soon, and now create code that's hard to maintain
    >>>for others. Yes, MIME::Lite takes like 10 minutes to understand,
    >>>and yes, I know reading doesn't look productive, but pressing all
    >>>those keys the whole day looks like a lot is going on. But no
    >>>serious programmer should do what you did.

    >>
    >>Sure, so I'm not a serious programmer. That didn't you take long to
    >>figure out, did it? I guess ten of thousands of satisfied users and
    >>mainatinable systems that run for years on years don't count. No, my
    >>less-than-dogmatic stance on reuse of modules dequalifies me
    >>completely.

    >
    > Your apparent unwillingness to step right up and discuss the
    > substantive issues raised by John B does rather convey a message, you
    > know.


    Oh yes? What message is that? That I suck at my job?

    > If you've been so widely active as you say, one wonders how many
    > maintenance programmers are cursing your name in the meantime (or
    > maybe they just tossed the code out and started again, as so often
    > happens with hand-knitted code).


    One wonders, but one doesn't know, does one? Tossing code out and
    starting over again can be a very healthy approach in my experience. One
    learns, doesn't one?

    >>>Yes, you created hard to maintain code, not a big deal if it's
    >>>your tool, but a big deal if others have to maintain it. Moreover,
    >>>you missed an opertunity to learn a new module, a big loss IMNSHO.

    >>
    >>You can't learn everything as every programmer knows...

    >
    > No disagreement there. However, using that as an excuse for publicly
    > refusing to learn more seems to me to be a sub-optimal way to proceed.


    Where did I publicly refuse to learn? When faced with a problem I once
    chose a simple homebrew solution instead of an available canned one. How
    is that "Publicly refusing to learn"?

    Or is refusing to agree with a fundamentalist application of principles
    'refusing to learn'. What do you want me to do? Confess? Repent?

    I for one wouldn't hire a programmer who demonstrates such rigidity as I
    meet here. I rather work with flexible people. But then again, I don't
    have to go begging for Perl jobs on the web, quite the contrary actually.

    Ximinez
    --
    Our three weapons are fear, surprise, and ruthless efficiency...
    and an almost fanatical devotion to the Pope....
    http://www.ai.mit.edu/people/paulfitz/spanish/t1.html
     
    The Spanish Inquisition, Jun 7, 2005
    #12
  13. John Bokma Guest

    The Spanish Inquisition wrote:

    > Alan J. Flavell wrote:
    >
    >> Your apparent unwillingness to step right up and discuss the
    >> substantive issues raised by John B does rather convey a message, you
    >> know.

    >
    > Oh yes? What message is that? That I suck at my job?


    No: that what you did, copy the source of a Thunderbird email message
    and tweaking, is something I certainly wouldn't recommend if others have
    to maintain the code at a point in time.

    As I stated: spending one hour, or even two, at studying MIME::Lite will
    give you the knowledge for not only solving the specific problem you
    had, but will also give you something that might come in handy in the
    feature.

    I admit that not all CPAN modules are perfect, but as I stated, they get
    better if people use them, instead of making up their own stuff.

    At one time I was working on a Perl application that had 600+ (!) hand
    coded Perl modules. About 6 people had been working on it, after each
    other. Quite a lot of modules had code that was redundant, either
    because someone else had added the code to another module, or worse, it
    was a copy paste job.

    Because everything was programmed in a hurry (since programming =
    pressing keys must have been the impression they, or at least the
    manager had) there was *zero* documentation.

    Now I claim that a lot of those modules could have been replaced by CPAN
    stuff. Yes, in some cases a wrapper would have been required.

    Oh, I was replacing a programmer who gave up after 3 months, who
    replaced a programmer who gave up after 3 months. I "left" them after a
    similar time (I got fired, for non-related things, if you want to know,
    email me). Anyway, I was already looking around for a different job.

    If a module does x% of what you want, it might save you time. If it's a
    well known module, and I think I can say that about MIME::Lite, you
    might make your code easier to maintain, since there is a probability
    that other programmers understand a part of your code, because they have
    seen it before.

    >> If you've been so widely active as you say, one wonders how many
    >> maintenance programmers are cursing your name in the meantime (or
    >> maybe they just tossed the code out and started again, as so often
    >> happens with hand-knitted code).

    >
    > One wonders, but one doesn't know, does one? Tossing code out and
    > starting over again can be a very healthy approach in my experience.
    > One learns, doesn't one?


    If you can toss out a CPAN module, and replace it by better code, please
    do so. You benefit, and maybe I benefit. And if your code is better, the
    person who is going to maintain your code might have already seen it.


    > Or is refusing to agree with a fundamentalist application of
    > principles 'refusing to learn'.


    I consider "my code is better than yours (CPAN)" quite a
    fundamentalistic view :-D

    > What do you want me to do? Confess? Repent?
    >
    > I for one wouldn't hire a programmer who demonstrates such rigidity as
    > I meet here.


    And I wouldn't hire a programmer who says: I copied the source of an
    email and tweaked it a bit, because it was faster then reading CPAN
    documentation :-D Especially since I might have to maintain that code.

    > I rather work with flexible people.


    Me too. And going to CPAN, picking a module, and taking the time to
    learn it is what I call fexible. Copy and pasting something and tweaking
    until it works, is not programming in my book.

    I know Perl is often used to write run once programs. But I started to
    keep those "run once" scripts, and notice that I often re use them,
    because I forced myself to even code what I consider run once code in
    such a way that I still can read it after 2 months.

    > But then again, I don't
    > have to go begging for Perl jobs on the web, quite the contrary
    > actually.


    I have to do that, for several reasons.

    --
    John Small Perl scripts: http://johnbokma.com/perl/
    Perl programmer available: http://castleamber.com/
    Happy Customers: http://castleamber.com/testimonials.html
     
    John Bokma, Jun 7, 2005
    #13
  14. On Tue, 7 Jun 2005, The Spanish Inquisition wrote:

    > Alan J. Flavell wrote:
    >
    > > Your apparent unwillingness to step right up and discuss the
    > > substantive issues raised by John B does rather convey a message,
    > > you know.

    >
    > Oh yes? What message is that? That I suck at my job?


    So you prove incapable of discussing substantive issues without
    reacting to them as a personal affront. Bye.
     
    Alan J. Flavell, Jun 8, 2005
    #14
  15. David Combs Guest

    In article <>,
    Alan J. Flavell <> wrote:
    >On Tue, 7 Jun 2005, The Spanish Inquisition wrote:
    >
    >> Alan J. Flavell wrote:
    >>
    >> > Your apparent unwillingness to step right up and discuss the
    >> > substantive issues raised by John B does rather convey a message,
    >> > you know.

    >>
    >> Oh yes? What message is that? That I suck at my job?

    >
    >So you prove incapable of discussing substantive issues without
    >reacting to them as a personal affront. Bye.


    It does seem that you guys are attacking him.

    And he's not saying that others should do the email-thing the way
    he does, only that he found that it worked for him.

    Besides, two hours of hard concentration on something (Mime::Lite?)
    during a packed-full day of putting out fires, is a lot to ask.

    (Do you have two hours available to learn some package that, say,
    because of your particular work, you might well never use again?)

    Looks like a one-sided religious war starting-up. :-(


    David
     
    David Combs, Jul 4, 2005
    #15
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. c# newbie
    Replies:
    3
    Views:
    5,900
  2. Guoqi Zheng

    mime multipart message

    Guoqi Zheng, May 22, 2004, in forum: ASP .Net
    Replies:
    0
    Views:
    501
    Guoqi Zheng
    May 22, 2004
  3. Matthew Zimmer

    Multipart Mime types from a client

    Matthew Zimmer, Jun 30, 2004, in forum: Java
    Replies:
    1
    Views:
    2,246
    Matthew Zimmer
    Jun 30, 2004
  4. Patrick
    Replies:
    0
    Views:
    330
    Patrick
    Feb 17, 2004
  5. Replies:
    1
    Views:
    412
Loading...

Share This Page