I'm still growling on this one... I send CLI email all the damn time via Linux or OSX, either with the output of a cron script or something along the lines of:
$ cat /var/log/maillog | mail -s root
or
$ mail root < /var/log/maillog
Works fine- no worries. But this morning I needed to send some larger files via attachment- and they were pretty huge, ~30megs and getting them there another way wasn't an option, so something like:
$ uuencode -m fulllogs.tar.gz - > fulllogs.tar.gz.uu$ mail root < fulllogs.tar.gz.uu
...just was going to suck, as once it'd been uuencoded it was more like 70+ megs... an email that big wasn't the problem, but I sure as hell didn't want to have to cut and paste all of the text and run it through a decoder and the standard mail doesn't allow for attachments. All I wanted to do was attach the damn thing.
I know mutt has some MIME attachment options, but try as I might I couldn't get it to work, but I did find metamail which fit the bill, which would encode the message, pipe it to splitmail to be broken up and then sent on it's merry way. You can set the size at which it splits... which I didn't at first, and ended up with 360 seperate emails hitting my account to be joined which the mail client choked on. But using something like:
$ metasend -e base64 -S 1000000 -f fulllogs.tar.gz
...broke it up into less pieces (with each individual file being much larger in bytes) that my mail client (GyazMail, OS 10.2) was able to join them, which brought me to my next hiccup. You can't save the joined email (which is straight forward to join, i'll give them that) but you can double click it and it pulls the file into stuffit expander, which decompresses it. Of course I couldn't find it to save the life of me, but I could see where stuffit said it was supposedly putting the files it'd just untarred. So I quit GyazMail, and did a:
% /usr/libexec/locate.updatedb% locate fulllogs...which of course are nowhere to be found. Non-deterred, I did a:
% /usr/libexec/locate.updatedb% sudo find / -iname "*fulllogs*" -print
...again, no love from the missing files. Fired up GyazMail, went through the process again, minus having to join the files... then did a search. Success! Stuffit was set to decompress the files into the directory in which the archive was stored- which is normally the preferred behavior, as if you double-click on a foo.tar.gz on your ~/Desktop, well, you want the decompressed foo/ to end up on your desktop. Unfortunately GyazMail was storing the mofo's in /private/tmp, and stuff was decompressing to /private/tmp, and when GyazMail quit the temp files associated with it were wiped away... taking the files I wanted with it.
Now I was really mad, as being able to do something like:
$ mutt -s "maillogs" -a "fulllogs.tar.gz" root
...should basically have done what I wanted, but I was getting thrown into some weird screen I couldn't get out of. Spent more time with it... and it turns out I'm just a moron. Since I hadn't specified a body, mutt was throwing me into "interactive mode"... in this case using vi as I hadn't set setenv for anything different. Since I never use vi, and am a pico -w guy when I am editing text via the CLI I didn't realize what I was in or how to get out of it. Turns out all vi was waiting for was "escape + : wq" and I was in the mutt client I expected... hit y, and the message and attachment sent out perfectly. Even worse, all I would have had to have done was a:
$ mutt -s "I Hate Mutt" -a "fulllogs.tar.gz" foo@bar < /dev/null
...would have sent it off perfectly the first time. Pretty stupid for it to have taken 3 hours to get it all sorted out, but I suppose it serves me right for sticking with pico instead of picking up vi which is du jour. Just plain stupid.
As an effort to wean myself back a bit from caffeine, I've started diluting the ratio of grounds to water in my coffee mixture. As in 5tbs grounds per pot, instead of my normal witches brew in the hope that I'll drink the same amount and just get less caffeine. Really not going well, it tastes like tea and I'm basically just making 10 pots every day instead of my normal 5-6. Not sure it's a good long-term solution... but hey, I'm making an effort as paltry as it is. The trick is that the less caffeine and nicotine I have, the easier I get frustrated and the more apt I am to somewhat-famous-caustic-emails.
Thanks to J for being so kind as to send me a CD, as a joke, called "Highway Music- Trucking Greats" which I think was supposed to annoy me, but I swear to god I like it much to her chagrin. First just because it made me laugh, but some of the stuff on there... "Teddy Bear", "Wolf Creek Pass", "Convoy", "Freightliner Fever", "I'll have another cup of coffee"...
I dunno, I still laugh whenever I listen to them but now found they've grown on me. The lyrics to some of them are just so damn dead-pan and wrong I can't help but laugh... I can't tell if they are supposed to be serious, and if they are I'm sorry... just can't help it. Thanks J.
That and this link I had passed onto me have been added straight to my stress-easing collection. I don't know why that link makes me laugh so hard, but it does. I think I'm just a sucker for logic gone awry... well that and when someone is beating themself up in a movie, like in "me, myself & irene" or "evil dead 2".
At any rate, since I've switched programs I had to rewrite my backup scripts... and also incorporate a backup of Apple's AddressBook database, as that's what GyazMail pulls from, rather than Entourage's route of a scary-as-hell-everything-in-a-proprietary-database-format-that-is-prone-to-corruption. Since a bunch of others seem to be switching to it from one program to another hopefully the script might be of use.
The script below isn't the prettiest thing in the world (it could use some more error-checking especially), but it gets the job done... It will backup local GyazMail files and the AddressBook database into compressed tar archives, then upload them to a remote location via
SSH. If you don't use remote backups, or use something like ftp for them (bad, bad user) just comment out the lines you don't want to operate (using the # sign before them) and you'll still have date-stamped archives of your files on your desktop.
Instructions for use:
Copy and paste the entire script below (you can leave out the description, but not the
#!/bin/sh) into a new file with the extension of .sh... i.e., emailbackup.sh. Save the file where you like, and from the terminal chmod the file to 755 so it will be executable. Ie, if the file was on the desktop and named as it is above, you would use the command:
% chmod 755 ~/Desktop/emailbackup.sh
The script pulls most of its data from variables declared at the top of the file, so you'll need to personalize a few of them, namely:
remoteUser, remoteHost & remotePath. These are the username for ssh, the hostname for ssh, and the path to the directory of where you want the files to be backed up on on the remote server. For example, if you're backing up to another OSX box using rendevous you'd use something like "db's-computer.local" for the hostname, or the IP address of one located on the net.
To execute the script, quit GyazMail and use the following command (assuming the script is on the desktop):
% sh ~/Desktop/emailbackup.sh
At which point it'll tell you everything it's done for the most part- you do have to quit GyazMail, unless you comment that part out... I've got that in there as it fits my automated backups scheme better. It works really well if you've created a key for your SSH sessions so that you don't have to authenticate- otherwise just enter your password when asked and watch it go.
#!/bin/sh
### Shell script to archive gyazmail email files and addressbook
### files to remote server for backups
###
### drunkenbatman
### 05.25.2003
## Define Variables
#Set Date
myDate=`date +%Y-%m-%d`
#Set User Name
User=`whoami`
#Set Cipher
cipher="-c blowfish"
#Set scp User
remoteUser="remote username here"
#Set host
remoteHost="remote ip or hostname here"
#Set Remote Path
remotePath="path to follow on remote host here"
## Say Hello
echo "Hello, $User. Beginning GyazMail Backup Script..."
## Check to see if GyazMail is running, and if so, end the script
echo "Checking for GyazMail..."
/bin/ps -xa | grep "GyazMail" | /usr/bin/grep -v grep > /dev/null
if [ $? -eq 0 ]
then
gyazPID=`ps -xa | grep "GyazMail" | grep -v grep | cut -c1-5`
echo "GyazMail is currently running at PID $gyazPID"
echo "Quit GyazMail and try again..."
exit 0
else
echo "GyazMail not running, continuing..."
fi
##Create Working Temp Folder on Desktop
echo "Creating temp directory on desktop..."
mkdir ~/Desktop/emailBackupTemp
echo "Temp directory created."
## Change to Backup Directory
cd /Users/$User/Library/ApplicationĄ Support/
echo "Directory changed to `pwd`..."
## Archive & Compress GyazMail and AddressBook files
echo "Tarring and compressing GyazMail files..."
tar -czf ~/Desktop/emailBackupTemp/$myDate-gyazbackup.tar.gz ./GyazMail/
echo "GyazMail files archived to temp folder."
echo "Tarring and compressing AddressBook files..."
tar -czf ~/Desktop/emailBackupTemp/$myDate-addressbackup.tar.gz ./AddressBook/
echo "AddressBook files archived to temp folder."
## Change to Backup Directory
cd ~/Desktop/emailBackupTemp/
echo "Directory changed to `pwd`..."
echo " "
## Upload Archives to Remote Host
echo "Uploading files to $remoteHost..."
for i in *.tar.gz
do
echo "Uploading ${i}"
/usr/bin/scp $cipher ${i} $remoteUser\@$remoteHost\:$remotePath
echo "Archived uploaded."
done
## Remove Local Temp Directory
cd ~/Desktop
rm -rf emailBackupTemp/
echo "Directory emailBackupTemp removed."
## Say Goodbye
echo " "
echo "Backups have been uploaded to $remotePath and removed."
echo "...shutting down."
##Exit
exit 0
## end of script
For some reason there ~100 requests a week for the old blog location and the old RDF feed. I figured that after 3 months whoever was linking there would catch on, but no such luck. Since I hate seeing unintentional failures in my error logs I created symlinks for the following two locations:
http://www.drunkenbatman.com/drunkenblog/ now points to:
http://www.drunkenbatman.com/
and
http://www.drunkenbatman.com/drunkenblog/index.rdf now points to:
http://www.drunkenbatman.com/index.rdf
At some point it's going to annoy me enough that I'll just remove them- so if you see this message in netnewswire please change your feed to what it should be... k? Appreciated...
I'll put up a quick tutorial on using symbolic and hard links for OSX users with apache or just in general over the next week hopefully as it can make things a lot easier when dealing with multiple volumes instead of having to download and use something like sharepoints.
Ah, and an update- I forgot that Apple changed some of the functionality from 10.1 to 10.2... everything that used to be stored in /usr/share/tcsh/ is now stored in /usr/share/tcsh/examples/ which can throw a few people if they haven't done the below commands. This can be a problem if you're trying to follow some of the things I've written...
Copying and pasting the below commands into a new terminal window will allow OSX to recognize the ~/Library/init/tcsh/ folder as well as some other basic aliases and auto-completion functionality.
If you're really curious about what you'll be getting by doing this, you'll want to read the files under "/usr/share/tcsh/examples".
There are two ways to get back that functionality, so I'll list them both here.
To just set it up for one user (ie, you) use the three commands below.
% echo "source /usr/share/tcsh/examples/rc" > ~/.tcshrc
% echo "source /usr/share/tcsh/examples/login" > ~/.login
% echo "source /usr/share/tcsh/examples/logout" > ~/.logout
If you wanted the new functionality to be system-wide (ie, every user gets it), you would use the below three commands:
% sudo echo "source /usr/share/tcsh/examples/rc" >> /etc/csh.cshrc
% sudo echo "source /usr/share/tcsh/examples/login" >> /etc/csh.login
% sudo echo "source /usr/share/tcsh/examples/logout" >> /etc/csh.logout
You'll want to make sure you don't have any .tcshrc, .login or .logout under your home folder (~) if you've implimented the second one.
No time for anything at the moment, least of all this. Hopefully, if I keep pushing I can be 90% caught up by late Sunday evening... made decent progress today, both in the social and work tasks I had set before me. w00t.
Had a craving since thursday to watch The Big Lebowski, but it can't be justified... must make do with the soundtrack for now.
Spam sucks, and believe me due to the things I have to deal with lately it's a problem that I don't take lightly. But thoughts this and this are a joke now-adays, as very, very few spammers are actually coming from where they say they're coming from.
Think about it this way:
If you get a piece of spam from lmnop@yahoo.com... it is not coming from yahoo, they've spoofed the headers. When you bounce it, you are faking an email from your host server to host that sent the message... but when they've faked the headers your bounced message hits yahoo, they see no user exists, and bounce it back to your ISP's server.
Something like 99.5% of spam uses forged headers now, simply because US and other countries ISP's apply a ton of pressure on any ISP down the chain to yank accounts for anyone found to be spamming. It's just more cost-effective for them to use out of country ISP's to funnel it all out already... You can blacklist and stop spam if you can know where it is coming from- but since they're forging headers you're just SOL.
There's a reason why baysean filtering is the most effective client and server side way to stop spam, but it's mostly useful on the client-side as it really needs some training. There are all sorts of technical ideas out there to stop spam completely, but the ones that would work are all based on being able to really tell where spam is coming from, or to at least have a way to know that mail coming to you should be coming to you.
None of have been implimented because they all require additions to RFC, a new spec, and things are just too entrenched... it would take half a dozen years for there to really be any effect and even then it could have a chilling effect on the net...
But that's beside the point- which is that if you could get people to overnight all upgrade and use a new spec for email, the problem would be pretty much solved.
If you actually taxed email, you'd have to do the same thing anyways- there's just no workable solution that would work without a new spec and infrastructure. If you didn't, nothing would change- spammers would still use forged headers to get their spam out from foreign hosts...
So, we have the problem that spam can't really be stopped without major technological changes (which haven't happened for a reason so far), but if they could be implimented would make spam a thing of the past. Yet, in order to tax email, you would have to impliment major technological changes to the net infrastructure...
Just kinda silly, IMHO. Chicken and egg... except that tax doesn't have to be there, and it won't have any consequence beyond chilling the parts that make the net so great. There'd be no mailing lists, no listervs, you'd pay the tax over and over: you don't think your ISP wouldn't pass on its additional costs on tech-support emails to you, or the costs for email support for any product you buy wouldn't be passed on?

posted on May 30, 2003 at 06:46 AM





