Re: Getting xfilter AND delivery to working

On Thu, 4 Feb 2016 20:53:49 -0700
Darren Spruell <[email protected]> wrote:

> On Feb 4, 2016, at 4:56 PM, Philip Rhoades <[email protected]> wrote:
> > 
> > Milan,
> >   
> >> On 2016-02-05 10:14, Milan Obuch wrote:
> >> On Fri, 05 Feb 2016 09:09:48 +1100
> >> Philip Rhoades <[email protected]> wrote:
> >>   
> >>> Milan,  
> >> 
> >> [ snip ]
> >>   
> >>>> So let me reiterate:
> >>>> - you receive mail
> >>>> - you need to extract attachment from it
> >>>> - you need to save original mail to designated folder
> >>>> 
> >>>> Did I understand it right?  
> >>> 
> >>> Correct.  
> >> 
> >> Nice, so see below.
> >> 
> >> [ snip ]
> >>   
> >>> You are probably right but I don't see how that helps solve the
> >>> problem . . I think it might be easier to take out the xfilter
> >>> line, let the mail be delivered as normal and set up an
> >>> inotifywait script to watch for new files in the appropriate mail
> >>> dir and then process them with my Ruby script . .  
> >> 
> >> No need to do it this way. All you need is just two lines:
> >> 
> >> `/home/phil/bin/bash_internal_variables.sh > /home/phil/t`
> >> to $DEFAULT/.tst/  
> > 
> > 
> > You must have missed my previous comment - while that DID work in
> > terms of creating the "t" file - the "to" line did NOT work - I
> > just tried it again - still not working . . this also failed:
> > 
> >   xfilter `/usr/bin/date > /home/phil/t`
> >   to $DEFAULT/.tst/  
> 
> Milan's example omitted 'xfilter.' No xfilter. Bad xfilter. 
> 
> - Darren
> 

Yes, exactly. While xfilter has its usage, in various cases, just not
this time.

So this does not work the way you want:

xfilter `/usr/bin/date > /home/phil/t`
to $DEFAULT/.tst/  

while next one should:

`/usr/bin/date > /home/phil/t`
to $DEFAULT/.tst/  

See the difference? Just xfilter deleted.

> >> (and replace bash_internal_variables.sh with your real script).
> >> That's all. Believe me, just try it. I did. And I am doing various
> >> things with maildrop. Some trial and error, some man pages reading
> >> is all that's required.  
> > 
> > Well I don't know what is wrong with my setup then . .
> > 

I hope you see it now.

> >> Now, we can go a bit deeper. If your original mail is correctly
> >> structured according MIME standard, which should be the norm
> >> nowadays, you could just use reformime. In my case, I use in one
> >> recipe the following:
> >> 
> >> PA=`reformime -e -s 1.1`
> >> 
> >> If mail MIME structure is the same everytime, there is nothing
> >> more to do, in your case, it could become
> >> 
> >> `reformime -e -s 1.2 > /home/phil/t`
> >> to $DEFAULT/.tst/
> >> 
> >> and you will have in file /home/phil/t just the attachment you
> >> wanted. You just need to adjust -s argument according your mail
> >> structure. It is possible to test structure with reformime with no
> >> arguments. For first experiments with reformime, you could just use
> >> 
> >> reformime < some_file_name_with_saved_mail
> >> 
> >> to check structure and then add some arguments to do other useful
> >> things.  
> > 
> > That is interesting but I have to do some processing on the
> > attachment before saving the output.
> > 

Well, no problem. From shell, you just use

reformime -e -s 1.2 < some_file_name_with_saved_mail | grep some_string

or

reformime -e -s 1.2 < some_file_name_with_saved_mail | perl some_script

or

reformime -e -s 1.2 < some_file_name_with_saved_mail | ruby some_script

or anything you like. reformime just saves you the work necessary to
extract attachment from raw mail message. You could see it as a 'save
attachment as' function. In my case, I am getting some mails with
base64 encoded attachment. With reformime, I need not to worry about
encoding, reformime does decoding for me as a bonus.

All this goes down just to 'use the tool designed for operation
desired' principle.

Naturally, you could do all this in your ruby script, but it will
become more complicated. And there is one basic rule for programming -
simpler is better.

Regards,
Milan

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140