Page 1 of 2 12 LastLast
Results 1 to 20 of 34
  1.    #1  
    For anyone who receives their mail at a UNIX shell account, you can use my sms_biff script to get notifications of incoming emails sent to your Treo via SMS.

    The notifications contain versions of the mail messages condensed to fit within the Sprint 160-byte SMS limit.
  2. #2  
    I don't know if you're familiar with Mercury, it's a free mail server that runs under Windows.

    It has fairly robust filter and policy features. If you have any general advice on how to use your script under windows, I'd appreciate it.
    --invention is the mother of necessity
  3. #3  
    Originally posted by markshelby
    I don't know if you're familiar with Mercury, it's a free mail server that runs under Windows.

    It has fairly robust filter and policy features. If you have any general advice on how to use your script under windows, I'd appreciate it.
    If dans script is perl based just get perl for windows. If it's a shell script then you'll have some conversion to do.
  4. #4  
    which brings up an interesting question - do we get charged per SMS? I supposed I could set up my mail to automatically foward or copy to my sprint-SMS e-mail address which would pretty much achieve the same thing.
  5.    #5  
    Originally posted by markshelby:
    I don't know if you're familiar with Mercury, it's a free mail server that runs under Windows.

    It has fairly robust filter and policy features. If you have any general advice on how to use your script under windows, I'd appreciate it.
    No, I'm not familiar with it. I forgot about the possibility of people running their own mail server on their Windows box. Yeah, my script could work under that situation too. Actually, it could also work in the case of a PC that's just a mail client (that's constantly polling for mail).

    The key is just whether the mail client or server's mail filtering setup gives you the ability to feed a copy of incoming mails to arbitrary external programs (and not consider that to represent the final delivery).

    Which Windows mail clients and servers offer that ability, I don't know.


    Originally posted by derek985:
    If dans script is perl based just get perl for windows.
    Yes, it's a Perl script, and should work under ActiveState Perl or Perl under Cygwin.

    However, the Mail::Mailer Perl module I use to send the mail will additionally require Net::SMTP to be installed to work on Windows (since neither the 'sendmail' nor 'qmail-inject' commands will be available).


    Originally posted by CySurflex:
    which brings up an interesting question - do we get charged per SMS?
    Not if you're on the PCS Vision flat-rate plan. Unlike most providers, Sprint doesn't charge a separate fee for SMS messages, and so as long as you're on the flat-rate plan, they're free.

    I supposed I could set up my mail to automatically foward or copy to my sprint-SMS e-mail address which would pretty much achieve the same thing.
    That's true, that's an option more people would probably have access to than the script-filtering option.

    Some major problems with that, though. If you forward via the usual methods of MIME encapsulation or the old plain text method:

    ------- Forwarded Message
    (original message)
    ------- End of Forwarded Message
    all the headers of the message you forward will be put in the body. The problem with this is that Sprint SMS messages (or Short Mail messages, to use their proprietary term) are limited to 160 characters. This would usually only get you to somewhere into the Received: headers before it hit the limit and crapped out. This wouldn't give you enough of (or the right portions of) the mail to be very useful.

    Even if you're able to send a copy of your incoming emails as-is to your SMS account, as would be the case if you got your mail server administrator to set up your address on the server to actually be a two-member list -- your local account plus your remote SMS account -- you'd still have a problem because Sprint strips off the headers of emails sent to phonenumber@messaging.sprintpcs.com. Therefore, you'd get the first 160 bytes of the message body, but no From:, Subject:, or other headers. Sometimes there'd be enough content in the first 160 bytes of the mail to make those unnecessary, but not usually.

    This is where sms_biff comes in. It takes the From: and Subject: headers and puts them in abbreviated form in the SMS message body. This is followed by as much of the original message body as will fit within the 160-byte limit. BTW, I've just updated the comments in sms_biff's header to make this a bit more clear. Please read it if for more details on sms_biff's operation.
    Last edited by Dan Harkless; 11/23/2002 at 06:07 AM.
  6.    #6  
    I just discovered that if you use your Sprint PCS email address (FLast##@sprintpcs.com), you can go to the PCS Mail Settings & Preferences page on Sprint's site and turn on "Notification by PCS Phone" for "All messages".

    With this on, each time you get a mail, you'll be sent an SMS message from No Caller ID saying:

    "Check your PCS Mail!"
    Not as useful as what sms_biff does, but a good option for people who use Sprint as their email provider and thus can't install sms_biff on their mail server.
    Last edited by Dan Harkless; 02/10/2003 at 03:48 PM.
  7.    #7  
    Yesterday Sprint modified their email-to-SMS gateway to extract From: and Subject: headers and put them in SMS message bodies. I've updated sms_biff accordingly.

    Please note that now in addition to the MailTools Perl module collection, you have to have the Net::SMTP module (part of the libnet collection) installed. Previously this was only necessary if you didn't have qmail-inject or sendmail on your system. This change was necessary to allow for proper error recovery as sms_biff now tries to forge SMS notification emails as being from the senders of the original incoming emails.
    Last edited by Dan Harkless; 01/24/2003 at 05:39 AM.
  8. #8  
    Originally posted by Dan Harkless
    Yesterday Sprint modified their email-to-SMS gateway to extract From: and Subject: headers and put them in SMS message bodies. I've updated sms_biff accordingly.

    Hi Dan,

    Thanks for posting the update; I've been using the old one for awhile now and it has been working quite well. I use it twofold; one is that I have a "pageme" adress where messages go directly to my phone and second, each time I get a message, I send a message with "new mail" in it down to my Treo 300. On my Treo 300, I'm running my NotifyMail program (still in development) which intercepts the SMS and then tells Mark/Space Mail to check mail (normal SMS messages are displayed).

    While there would have been other ways to do SMS, your script is elegant and much appreciated.

    Thanks!
  9.    #9  
    Originally posted by sgruby
    Thanks for posting the update; I've been using the old one for awhile now and it has been working quite well. I use it twofold; one is that I have a "pageme" adress where messages go directly to my phone and second, each time I get a message, I send a message with "new mail" in it down to my Treo 300. On my Treo 300, I'm running my NotifyMail program (still in development) which intercepts the SMS and then tells Mark/Space Mail to check mail (normal SMS messages are displayed).

    While there would have been other ways to do SMS, your script is elegant and much appreciated.
    Cool! Very glad to hear that it's successfully operating as part of your overall system.

    BTW, for anyone upgrading, I forgot to mention above along with the new module requirement that I also renamed all of sms_biff's environment variables to start with "sms_biff_" (for readability and to prevent environment namespace pollution).

    The one mandatory environment variable, which used to be called SMS_BIFF_EMAIL (this one, unlike the others, already had the "sms_biff_" prefix, though with a different capitalization), is now sms_biff_SMS_EMAIL_ADDRESS.
    Last edited by Dan Harkless; 01/24/2003 at 06:05 PM.
  10. #10  
    Dan,

    I've got the sms_biff up and working on my mail server in conjunction with spambouncer (I posted a question on another thread). I've added:

    :0 c
    * ? test -f ${MYEMAIL} && \
    (${FORMAIL} -zxTo: -zxCc: |\
    fgrep -i -f ${MYEMAIL})
    *$ !^$X_LOOP
    | sms_biff

    Right before:

    :0:
    * ? test -f ${MYEMAIL} && \
    (${FORMAIL} -zxTo: -zxCc: |\
    fgrep -i -f ${MYEMAIL})
    | ${FORMAIL} -A"X-Folder: Default" >>${DEFAULT}

    In my .procmailrc file.

    This causes any email that passes spambouncer test and matches one of my own email addresses to get sent to sms_biff and also get filed in my DEFAULT folder.

    Very cool! I've been thinking about this for a couple of weeks and was thinking of somehow using a a cron job or something but sms_biff is an elegant solution!
  11.    #11  
    Originally posted by philipgood
    I've got the sms_biff up and working on my mail server in conjunction with spambouncer (I posted a question on another thread). I've added:

    :0 c
    * ? test -f ${MYEMAIL} && \
    (${FORMAIL} -zxTo: -zxCc: |\
    fgrep -i -f ${MYEMAIL})
    *$ !^$X_LOOP
    | sms_biff

    Right before:

    :0:
    * ? test -f ${MYEMAIL} && \
    (${FORMAIL} -zxTo: -zxCc: |\
    fgrep -i -f ${MYEMAIL})
    | ${FORMAIL} -A"X-Folder: Default" >>${DEFAULT}
    Ah, so that was the only line in that recipe. I see. Okay, yeah, just duplicating all those commands on the two recipes is one way to go. I do think you could avoid that by rearranging your logic, but again, I'm no procmail expert.

    Actually, now that I think about it, since you're using this unconventional (to me) way of manually appending your mail to your mailbox, one way you could avoid duplicating the commands is to add "| tpipe sms_biff" just before the ">>" on your main recipe (and getting rid of the ":0 c" recipe), if you have tpipe installed on your box.

    Very cool! I've been thinking about this for a couple of weeks and was thinking of somehow using a a cron job or something but sms_biff is an elegant solution!
    Great! Glad you've found it useful.
    Last edited by Dan Harkless; 01/24/2003 at 08:12 PM.
  12. #12  
    Originally posted by Dan Harkless

    Actually, now that I think about it, since you're using this unconventional (to me) way of manually appending your mail to your mailbox, one way you could avoid duplicating the commands is to add "| tpipe sms_biff" just before the ">>" on your main recipe (and getting rid of the ":0 c" recipe), if you have tpipe installed on your box.

    Great! Glad you've found it useful.
    Spambouncer (spambouncer.org) is not so unconventional. It's server side spam filtering. It works in combination with procmail and filters incoming mail through any number of spam lists, modifies the header of the emails accordingly so they can be easily filtered by a client mail program. It can bounce, discard or report the spam and also can filter the spam into folders on the server. I filter all suspected spam into server side folders and browse through those occasionally for mistaken spam. This way, I only get real non-spam mail in my inbox when I check it from a web interface or with Snappermail.

    I don't have tpipe installed on my server (RH7). I figure there is probably a better way than the way I am currently implementing sms_biff but it works for now.

    Thanks again,
    Phil
  13.    #13  
    Originally posted by philipgood
    Spambouncer (spambouncer.org) is not so unconventional.
    I didn't say spambouncer was unconventional -- just your use of ">>" in conjunction with formail to manually append to your mailbox. What's usually seen is to use a "filter" recipe to add headers, and then deliver with procmail's default action, like:

    :0 fw
    | formail -A "X-Folder: Default"

    :0 :
    ${DEFAULT}
    Not that there's necessarily anything wrong with the way you're doing it (other than the fact that you have to duplicate commands on multiple recipes) -- I just haven't seen it done that way before.

    I don't have tpipe installed on my server (RH7).
    Yeah, I was surprised to find that my Red Hat system with all RPMs installed didn't have it. Well, if you want to try it out, you can try compiling it from the source. In some brief searching, I didn't find any newer copies than this one from 1990.

    I figure there is probably a better way than the way I am currently implementing sms_biff but it works for now.
    Yup, if it ain't broke...
  14.    #14  
    I discovered the other day that Sprint unconditionally reserves space for the From and Subject pseudo-headers that it's been putting in SMS message bodies since January 23. So whether you use those headers in full or not, SMS message bodies are now limited to 91 characters rather than the advertised (and formerly accurate) 160.

    Until now I'd been using sms_biff's sms_biff_MAKE_BODY_SUBJECT feature so I could get subjects longer than Sprint's 32-character limit.

    However, now I see that using that means that I completely miss out on being able to utilize those 32 characters (34 including the trailing ": "). I still want to be able to receive longer subjects, though, so I've implemented a new "continuation" feature.

    sms_biff_MAKE_BODY_SUBJECT has been renamed to sms_biff_BODY_SUBJECT_CONSTRUCT (to coincide with the naming of some other related environment variables I added), and if you set it to "continuation", sms_biff will let Sprint's pseudo-header handle the first 32 characters of the subject, and then it will be responsible for the rest (up to sms_biff_BODY_SUBJECT_TOTAL_MAX characters, split off from the old sms_biff_MAX_BODY_HEADER_LEN variable that controlled both From and Subject pseudo-headers). This way, as little space as possible is wasted, and now more of the email body can be seen in the notification.

    If you use the "continuation" feature, I'd also suggest setting the new sms_biff_UNLABELED_HEADERS to either "newline" or "space" to get Sprint-style pseudo-headers, which read more easily when headers are broken into a Sprint-generated piece and an sms_biff-generated piece.

    For more details on the new features, see the documentation in sms_biff's header.
  15.    #15  
    Minor update to sms_biff. I didn't realize that the Mail::Header object was folding long header lines regardless of whether or not they were folded in the original email, meaning wasteful "<newline><space><space><space><space>" sequences were getting put in SMS notifications of emails with long subjects.
  16.    #16  
    sms_biff has been updated.

    There's a bug in Sprint's email-to-SMS gateway where if you send it an email with a blank body (i.e. entire message is in the Subject: line), the SMS message will consist of just the From: pseudo-header and a portion of the first Received: line. The Subject: pseudo-header will not appear.

    To work around this bug, you can set sms_biff's new sms_biff_EMPTY_BODY_FILLER environment variable to 1. This will cause the string:

    [fake body to work around empty body bug in email-to-SMS gateway]
    to be added in the SMS email body if it would otherwise be blank.

    Thanks to David Blank-Edelman for making me aware of this issue.
  17.    #17  
    Updated sms_biff again today.

    I've added new configuration variables called sms_biff_FILTER_BODY, sms_biff_FILTER_SUBJECT, and sms_biff_FILTER_SQZ_OPTIMIZE_LEVEL. These allow you to filter the body and/or subject through particular Perl modules to compact the text and make better use of the small SMS message size.

    Currently supported modules are Lingua::EN::Keywords, Lingua::EN::Squeeze, and Lingua::EN::Summarize.

    You can even have sms_biff use multiple of those filters in sequence -- see the documentation in sms_biff's header for the full details. Personally, I'm now using:

    sms_biff_FILTER_BODY = Lingua::EN::Summarize
    sms_biff_FILTER_SUBJECT = Lingua::EN::Squeeze
    in my .procmailrc.

    I had already been planning the summarizing feature, but thanks very much to David Blank-Edelman for pointing out the Lingua::EN::Squeeze module.
  18.    #18  
    Sorry for two updates in one day, but while thinking in the shower (always good for a brainstorm or two), I realized it would be a lot more flexible (and not much more work to implement) to change the lists of filters to being lists of pipelines of filters.

    If an individual filter pipeline (separated by ','s) fails to shrink the content enough to fit within the space allotted, the content will be unchanged and the next pipeline will be tried.

    The individual filters (separated by '|'s) within each pipeline, on the other hand, are unconditionally cumulative with respect to each other.

    Because the sms_biff_FILTER_{BODY,SUBJECT} settings are now likely to be quite a bit longer, I renamed the filter options. Rather than being named after the module they're found in, they're named after the function itself. So now:

    • "Lingua::EN::Keywords" has become "keywords"
    • "Lingua::EN::Squeeze" has become "SqueezeText"
    • "Lingua::EN::Summarize" has become "summarize"
    I've also added a new filter which is built-in to sms_biff. It's called "rm_ws" and it removes all whitespace and CausesWordBoundariesToBeMarkedWithCapitalsLikeThis. This obsoletes the old sms_biff_FILTER_SQZ_OPTIMIZE_LEVEL variable, so that's been removed.

    Here're the settings I have for the two variables in my .procmailrc under the new system:

    sms_biff_FILTER_BODY = "rm_ws,"\
    "SqueezeText,SqueezeText|rm_ws,"\
    "summarize,summarize|rm_ws,summarize|SqueezeText,summarize|SqueezeText|rm_ws,"\
    "keywords,keywords|rm_ws,keywords|SqueezeText,keywords|SqueezeText|rm_ws"

    sms_biff_FILTER_SUBJECT = $sms_biff_FILTER_BODY
    As you can see, the filter pipelines are organized in increasing order of "destructiveness" to the content.

    I've also added a new variable called sms_biff_FILTER_MAX_INPUT_LEN which defaults to 1024. This was necessary because some of the filters were taking ten billion years to run on bodies containing large binary attachments. (Ideally such attachments wouldn't be run through the filters at all, of course, but that will have to wait for me to implement MIME parsing.)

    As usual, for the full details on the changes, see the documentation in sms_biff's header.
  19.    #19  
    Sorry, just discovered a bug that would occur if the final filter of the final pipeline wasn't able to shrink content to within $limit. If you downloaded sms_biff since my last post, please grab it one more time.

    This should be the last one for today...
  20.    #20  
    Updated sms_biff today, but it's not an update that there's any need to download. I just added a TO DO to support Sprint's web-to-SMS gateway now that they've fixed it to not limit SMS message length to 91 characters, and a warning not to mistype your sms_biff_SMS_EMAIL_ADDRESS since sms_biff's forging of the envelope From (necessary with Sprint's email-to-SMS gateway) will cause any bounces of the SMS emails to go not to you, but to the people sending you mail.

    The more interesting news is my new TreoVisorCentral_notification script, which can be used in conjunction with sms_biff to specially filter your TreoCentral "Reply to post" and "New Private Message" emails so that you'll be able to browse to the new message(s) directly from the SMS popup on your Treo, using either the special mobile version of the discussion board or the normal one, at your discretion.
Page 1 of 2 12 LastLast

Posting Permissions