Read the mail attachment from Linux command line - linux

Is it possible to read the emails based on the Subject line and then get the base64 attachment or directly get the attachment ?
Server : Linux System

Your question seems to presuppose that there is a single attachment and that it can be reliably extracted. In the general case, an email message can have a basically infinite amount of attachments, and the encoding could be one out of several.
But if we assume that you are dealing with a single sender which consistently uses a static message template where the first base64 attachment is always going to be the one you want, something like
case $(formail -zcxSubject: <"$message") in
"Hello, here is your report for "*)
awk 'BEGIN { h=1 }
h { if ($0 ~ /^$/) h=0 ; next } # skip headers
/^Content-Disposition: attachment/ { a=1 } # find att
a && /^$/ { p=1; next }
p && /^$/ { exit }
p' "$message" |
base64 -d ;;
esac
This will extract the Subject: header and compare it to a glob pattern. I expect this is what you mean by "based on subject" -- if we find a matching subject header, examine this message, otherwise discard.
The crude Awk script attempts to isolate the base64 data and pass it to base64 -d for extraction. This contains a number of pesky and somewhat crude assumptions about the message format, and probably requires significant additional tweaking. Briefly, we skip the headers, then look for MIME headers identifying an attachment, and print that, skipping everything else in the message. If this header is missing, or identifies the wrong MIME part, you will get no results, or (worse) incorrect results. Also, the /^Content-Disposition:/ regex could theoretically match on a line which is not a MIME header, though this seems highly unlikely (but might actually happen if you are looking e.g. at a bounce message).
A more robust approach would involve a MIME extraction tool or perhaps a custom script to actually parse the MIME structure and extract the part you want. Without details about what exactly you need, I'm not able to provide that. (This would also allow you to use the sender's specified filename; the above script simply prints the decoded payload to standard output.)
Note also that formail has no idea about RFC2047 encoding, so if the subject is not plain ASCII, you have to specify the encoded form in the script.

Related

sendmail add a second attachment to an email

Have a program that issues the following command at the linux level
EXE1= "SH -c '/usr/lib/sendmail ":EMAIL<1,X>:' < "/thisdata/level1/VRE/&HOLD&/':PC.FILE:'.CSV':'"':"'"
Is it possible to attach a second PC.File in this instruction?
The rightest answer to this would require knowledge of OS and any mail server restrictions you might have but I have been working on an old routine of ours that maybe provide some insight.
We used to us uuencode as #RedCabbage suggested but we had problems with some servers rejecting the messages. As we have no control over other people's servers and because uuencode is almost as old as dirt we updated our solution to use MIME instead. See "Not As Easy Way"
Easy way
On our Linux system we use mailx (which in our case linked to /usr/bin/mail) to add multiple attachments.
echo "It's Wednessday, my dudes." |mail -s "foobar" -a foo.txt -a bar.txt dudes#wednessday.com
This results in an email with two attachments and message body if the files are properly pathed (if used with a real address).
Not As Easy Way
Create your own MIME (multipart/mixed) message. We create a record similar to this.
To: foo#foo.bar
From: bar#foo.bar
Subject: Not Rocket Surgery
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="SomelongBoundryMarkerYouMakeUpDoNotUseThis"
This is a multipart message in MIME format.
--SomelongBoundryMarkerYouMakeUpDoNotUseThis
Content-Type: text/plain
The body of that message go here.
--SomelongBoundryMarkerYouMakeUpDoNotUseThis
Content-Type: application/pdf
Content-Transfer-Encoding: Base64
Content-Disposition: attachment; filename="YourFileName.pdf"
Content-Base: http://www.IputOurDomainHereDunnoWhyDoNotUseThis.com
##BASE64 encoded string go here.
--SomelongBoundryMarkerYouMakeUpDoNotUseThis
Rinse and Repeat with more files, newlines are important here.
For the encoding part, assuming that your file is in /foo/bar.pdf
ENCODED = ""
FILE.LOC = "/foo/bar.pdf"
TEST = ENCODE("Base64",1,FILE.LOC,2,ENCODED,1)
IF TEST EQ 0 THEN
;*Put the text in ENCODED where it says ##BASE64 encoded string go here
END
This is much more tedious because you have to figure out the all the mime types and make sure everything is formatted just right.
Good Luck
This is how we have managed multiple attachments. For example, /home/jbloggs/attachment1.doc /home/jbloggs/attachment2.pdf.
You will (as you have done) have to build the commands and execute them with SH -c 'blah' (as you have done already.)
Create a text file with the address, subject and body in (for example) /home/jbloggs/tempemail.txt
To: recipient.email#gmail.com
subject: Your subject line here
This is the main body text
Cycle through the attachments and uuencode them to an incrementing name (ENCODEDn here):
uuencode /home/jbloggs/attachment1.doc attachment1.doc > ENCODED1
uuencode /home/jbloggs/attachment2.pdf attachment2.pdf > ENCODED2
Use cat to join all the files together to a single one:
cat /home/jbloggs/tempemail.txt ENCODED1 ENCODED2 > COMBOFILE
Use sendmail on the combo:
sendmail recipient.email#gmail.com < COMBOFILE
You can loop through as many ENCODEDn files as you like.

Use Japanese characters in subject and attach file with mailx in RedHat Linux

I am trying to use the mailx command for sending email with attachment (zipped) and am facing two issues, below is the command I use:
(echo "$BODY"; UUENCODE $ZIP_FILE $ZIP_FILE) \
| mailx -s $SUBJECT_1 -r " " $SENDER $RECIPIENT
My email subject contains space and Japanese characters.
The variable $SUBJECT_1 has the following statement
Subject: [Budget] Subtype Error and some JAPANESE CHARECTERS
I get bet following error:
contains invalid character '\203'
Moreover for testing purpose I changed the statement of SUBJECT_1 to Test Message
SUBJECT_1="Test Message"
It worked, but I receive only Test instead of Test Message and in the mail I could see two more email ids in the To like Message#domain.com and -r#domain.com
I have not implemented the mail body yet, once subject issue fixed will implement the same in body because Body will also have Japanese characters.
Please help me with this error, how to resolve and what am i doing wrong
There's a list of things you need help with here, more than I want to to handle exhaustively on a sunny Saturday afternoon. But some hints.
Quote your variables.
"$SUBJECT_1" is a single string, whereas $SUBJECT_1 is a list of space-separated words. The second word is your email recipient, and subsequent options are also recipients.
Subject.
The basic idea is that you need to include encoding data in the subject, because email headers are only supposed to include 7-bit ASCII.
Here is a hint at how you put special characters in your Subject line.
Here is another hint.
Here is the RFC that describes in lurid detail what you need to do. Asking your favourite search engine for information about "utf8 email subject" and "rfc1522" is probably a good idea.
Email client.
Finally, rather than learning how to use MIME, consider using mutt instead of mailx to send your mail. Mutt has a -a option to add attachments, making it WAY easier than constructing your own headers and body, which I'm not even sure you'd be able to do with mailx in the first place.

What command to search for ID in .bz2 file?

I am new to Linux and I'm trying to look for an ID number within a .bz2 file. Seems like a fairly straight forward requirement, however I cannot find the correct command anywhere online. I believe I need to use bzgrep.
I want to look for '123456' in the file Bulk9876.bz2
How would I construct this command?
You probably just need to tell grep that it's okay to parse that data as text:
bzgrep -a 123456 Bulk9876.bz2
If you're trying to view the compressed data (rather than decompressing it and searching the decompressed data), just use grep -a ….
Otherwise, it might make sense to verify that the desired string is even present in the file; bunzip2 it and grep -a the decompressed file. If that works, the problem is in your bzgrep instance (which is odd because it should be using the same decompression library as bunzip2).

Cleaning a text-mail after/before a procmail process in order to have a print of that mail

I've to clean some mails in order to print only their body with procmail :
:0: # printing mail with bb in the subject to bbprinter
* ^Subject:.*bb
| lpr -Pbbprinter
How should I make that ?
Any idea-help welcome
Your question is ill-defined in a number of ways. What do you mean by "clean"? What do you mean by "body"?
If you mean, how can I send just the RFC5322 body, not the headers, to the printer, that's easy:
:0b
* ^Subject:.*bb
| lpr -Pbbprinter
Notice the b flag there after the :0, which restricts the scope of the action to just the body.
But with MIME, you frequently don't actually want the RFC5322 body (that is, everything after the last header line) but rather only one part out of a MIME multipart message. You would need to come up with some analysis of which part to extract, but if you have that, it's still easy:
:0
* ^Subject:.*bb
| parse-out-preferred-mime-body-part | lpr -Pbbprinter
(We don't use :0b here because a proper MIME parser needs access to the top-level RFC5322 headers, too.)
If by "clean" you mean something else, or in addition, you will have to clarify your question, but the general idea is something like
:0
* ^Subject:.*bb
| cleanupbody | lpr -Pbbprinter
where cleanupbody could perform whatever you mean by "cleanup" (blot out curse words? Fix common typos? More or less the same thing?)
Finally, just to wrap up, you can basically pipe to a shell script of any complexity (although by the time it spans more than a few lines, you are probably better off moving all or parts of it to a separate script, perhaps with a test suite of its own).
:0
* ^Subject:.*bb
| parse-out-preferred-mime-body-part | \
sed -e 's/grammer/grammar/g' -e 's/seperate/separate/g' \
-e 's/definately/definitely/g' | \
lpr -Pbbprinter

Decode a string with unknown encode method received from web-browser

inside a webapplication i am processing requests to a url like
http://example.com/<website-base-url>
im am logging the raw GET parameter of the request in an uft8 database column and in filesystem. for a few chinese domains i get requests with a website-base-url parameter like
%C3%83%C2%A3%C3%82%C2%A5%C3%83%C2%A2%C3%82%C2%A4%C3%83%C2%A2%C3%82%C2%A7%C3%83%C2%A3%C3%82%C2%A5%C3%83%C2%A2%C3%82%C2%A4%C3%83%C2%A2%C3%82%C2%B4%C3%83%C2%A3%C3%82%C2%A8%C3%83%C2%A2%C3%82%C2%B4%C3%83%C2%A2%C3%82%C2%B4.cn
Decoding with urldecode returns
ã¥â¤â§ã¥â¤â´ã¨â´â´.cn
This does not seem to be the domain name the user wants to request.
I have tried urlencoding, base64, utf8 and combinations wihtout success.
Any suggestions how decode the given parameter to utf8?
URL percentage encodings simply encode the raw bytes. It does not give you any hint regarding the actual encoding of the text. If you do not know what encoding these bytes represent, all you can do is guess.
php > $d = urldecode('%C3%83%C2%A3%C3%82%C2%A5%C3%83%C2%A2%C3%82%C2%A4%C3%83%C2%A2%C3%82%C2%A7%C3%83%C2%A3%C3%82%C2%A5%C3%83%C2%A2%C3%82%C2%A4%C3%83%C2%A2%C3%82%C2%B4%C3%83%C2%A3%C3%82%C2%A8%C3%83%C2%A2%C3%82%C2%B4%C3%83%C2%A2%C3%82%C2%B4.cn');
php > echo $d;
ã¥â¤â§ã¥â¤â´ã¨â´â´.cn
php > echo iconv('BIG5', 'UTF-8', $d);
php > echo iconv('Shift-JIS', 'UTF-8', $d);
テδ」テつ・テδ「テつ、テδ「テつァテδ」テつ・テδ「テつ、テδ「テつエテδ」テつィテδ「テつエテδ「テつエ.cn
php > echo iconv('GB18030', 'UTF-8', $d);
脙拢脗楼脙垄脗陇脙垄脗搂脙拢脗楼脙垄脗陇脙垄脗麓脙拢脗篓脙垄脗麓脙垄脗麓.cn
GB18030 would seem to be the best candidate, but even that decoded string looks a bit too repetitive to be really useful Chinese.

Resources