Validity of this e-mail structure

Sorry guys if this is the wrong ng for this post - wasn't sure where
it should go so thought I'd try here first.

The following is the content (less a chunk of the encoded attachment)
of a file on the o/s (Solaris 9) called e-mail.txt.

The following command is being executed:

/usr/lib/sendmail -t -f replies@domain.com < email.txt

In my e-mail client (Outlook) I see a well-formed e-mail message and
an attachment. If I send to another user (a customer) they see the
encoded content in-line with no atachment (using the same client).

What I would like to do is to understand if there is something in the
structure of the file email.txt which is wrong but may be tolerated by
some e-mail clients but not by others? The customer is running the
same Outlook client but with some add-ins that we don't have. It is
only one customer (though multiple users within that customer) who
experience this behaviour. Which actually suggests to me that their
mail server might not like the structure of the email?

Really grateful for any suggestions as this has me really stumped.


-- email.txt content starts line below ---
To: jeremy@abcdef.xyz
Subject: Attached files
From: jeremy@abcdef.xyz
Cc: jeremy@abcdef.xyz

Please see attached

-- email.txt content ends line above ---


--
jeremy

Re: Validity of this e-mail structure [uuencode v. MIME]

jeremy writes:

> Sorry guys if this is the wrong ng for this post - wasn't sure where
> it should go so thought I'd try here first.
>
> The following is the content (less a chunk of the encoded attachment)
> of a file on the o/s (Solaris 9) called e-mail.txt.
>
> The following command is being executed:
>
> /usr/lib/sendmail -t -f replies@domain.com < email.txt
>
> In my e-mail client (Outlook) I see a well-formed e-mail message and
> an attachment. If I send to another user (a customer) they see the
> encoded content in-line with no atachment (using the same client).
>
> What I would like to do is to understand if there is something in the
> structure of the file email.txt which is wrong but may be tolerated by
> some e-mail clients but not by others? The customer is running the
> same Outlook client but with some add-ins that we don't have. It is
> only one customer (though multiple users within that customer) who
> experience this behaviour. Which actually suggests to me that their
> mail server might not like the structure of the email?
>
> Really grateful for any suggestions as this has me really stumped.
>
>
> -- email.txt content starts line below ---
> To: jeremy@abcdef.xyz
> Subject: Attached files
> From: jeremy@abcdef.xyz
> Cc: jeremy@abcdef.xyz
>
> Please see attached
>
> begin 644 cv_Jim60_Jim60.doc
> MT,\1X*&Q&N$ /@ # /[_"0 & !
> [...]
> E
>
> end
> -- email.txt content ends line above ---

Have you tried to use MIME instead of uuencode?
[ initially for this recipient only ]

I would suggest (initially?) to use MIME::Lite perl module from CPAN for
generating MIME messages with attachments.

--
[pl>en: Andrew] Andrzej Adam Filip : anfi@priv.onet.pl : anfi@xl.wp.pl
Open-Sendmail: http://open-sendmail.sourceforge.net/

Re: Validity of this e-mail structure [uuencode v. MIME]

On Nov 21, 10:19 am, Andrzej Adam Filip wrote:
> jeremy writes:
> > Sorry guys if this is the wrong ng for this post - wasn't sure where
> > it should go so thought I'd try here first.
>
> > The following is the content (less a chunk of the encoded attachment)
> > of a file on the o/s (Solaris 9) called e-mail.txt.
>
> > The following command is being executed:
>
> > /usr/lib/sendmail -t -f repl...@domain.com < email.txt
>
> > In my e-mail client (Outlook) I see a well-formed e-mail message and
> > an attachment. If I send to another user (a customer) they see the
> > encoded content in-line with no atachment (using the same client).
>
> > What I would like to do is to understand if there is something in the
> > structure of the file email.txt which is wrong but may be tolerated by
> > some e-mail clients but not by others? The customer is running the
> > same Outlook client but with some add-ins that we don't have. It is
> > only one customer (though multiple users within that customer) who
> > experience this behaviour. Which actually suggests to me that their
> > mail server might not like the structure of the email?
>
> > Really grateful for any suggestions as this has me really stumped.
>
> > -- email.txt content starts line below ---
> > To: jer...@abcdef.xyz
> > Subject: Attached files
> > From: jer...@abcdef.xyz
> > Cc: jer...@abcdef.xyz
>
> > Please see attached
>
> > begin 644 cv_Jim60_Jim60.doc
> > MT,\1X*&Q&N$ /@ # /[_"0 & !
> > [...]
> > E
>
> > end
> > -- email.txt content ends line above ---
>
> Have you tried to use MIME instead of uuencode?
> [ initially for this recipient only ]
>
> I would suggest (initially?) to use MIME::Lite perl module from CPAN for
> generating MIME messages with attachments.
>

Hi thanks for the response - why should uuencode cause problems?

--
jeremy

Re: Validity of this e-mail structure [uuencode v. MIME]

jeremy writes:

> On Nov 21, 10:19 am, Andrzej Adam Filip wrote:
>> jeremy writes:
>> > Sorry guys if this is the wrong ng for this post - wasn't sure where
>> > it should go so thought I'd try here first.
>>
>> > The following is the content (less a chunk of the encoded attachment)
>> > of a file on the o/s (Solaris 9) called e-mail.txt.
>>
>> > The following command is being executed:
>>
>> > /usr/lib/sendmail -t -f repl...@domain.com < email.txt
>>
>> > In my e-mail client (Outlook) I see a well-formed e-mail message and
>> > an attachment. If I send to another user (a customer) they see the
>> > encoded content in-line with no atachment (using the same client).
>>
>> > What I would like to do is to understand if there is something in the
>> > structure of the file email.txt which is wrong but may be tolerated by
>> > some e-mail clients but not by others? The customer is running the
>> > same Outlook client but with some add-ins that we don't have. It is
>> > only one customer (though multiple users within that customer) who
>> > experience this behaviour. Which actually suggests to me that their
>> > mail server might not like the structure of the email?
>>
>> > Really grateful for any suggestions as this has me really stumped.
>>
>> > -- email.txt content starts line below ---
>> > To: jer...@abcdef.xyz
>> > Subject: Attached files
>> > From: jer...@abcdef.xyz
>> > Cc: jer...@abcdef.xyz
>>
>> > Please see attached
>>
>> > begin 644 cv_Jim60_Jim60.doc
>> > MT,\1X*&Q&N$ /@ # /[_"0 & !
>> > [...]
>> > E
>>
>> > end
>> > -- email.txt content ends line above ---
>>
>> Have you tried to use MIME instead of uuencode?
>> [ initially for this recipient only ]
>>
>> I would suggest (initially?) to use MIME::Lite perl module from CPAN for
>> generating MIME messages with attachments.
>>
>
> Hi thanks for the response - why should uuencode cause problems?

* MUA of the recipient may be unable to support uuencode
* MUA of the recipient may be configured to "ignore" uuencode
* MTA on the path may give uuencode "special treatment"
* ...

Anyway I suggest using MIME instead of uuencode even without problems
with uuencode handling.

BTW try to avoid sending MS Word (*.doc) documents over email.
Many postmasters treat any attachment that may contain "unfriendly"
macros with suspicion. I personally would recommend using MTA level
filters to convert *.doc into *.txt ["medium strength recommendation].

--
[pl>en: Andrew] Andrzej Adam Filip : anfi@priv.onet.pl : anfi@xl.wp.pl
Open-Sendmail: http://open-sendmail.sourceforge.net/

Re: Validity of this e-mail structure

On Wed, 21 Nov 2007 02:09:32 -0800 (PST), jeremy wrote:
> Sorry guys if this is the wrong ng for this post - wasn't sure where
> it should go so thought I'd try here first.
>
> The following is the content (less a chunk of the encoded attachment)
> of a file on the o/s (Solaris 9) called e-mail.txt.
>
> The following command is being executed:
>
> /usr/lib/sendmail -t -f replies@domain.com < email.txt
>
> In my e-mail client (Outlook) I see a well-formed e-mail message and
> an attachment. If I send to another user (a customer) they see the
> encoded content in-line with no atachment (using the same client).
>
> [...]
> -- email.txt content starts line below ---
> To: jeremy@abcdef.xyz
> Subject: Attached files
> From: jeremy@abcdef.xyz
> Cc: jeremy@abcdef.xyz
>
> Please see attached
>
> [2. attachment]
> -- email.txt content ends line above ---

The attachment is ``inline'', but it is encoded using ``uuencode
format''. Some mail-user agents can decode these on the fly. Some
newsreaders can do this too. For example Gnus -- which is what I use to
read the newsgroup -- can decode this sort of inline attachment just
fine.

But you can't depend on *any* mailer to be able to decode this sort of
inline attachment these days. It's probably a good idea to use MIME to
attach the file :-/