Page 2 of 2 FirstFirst 12
Results 21 to 34 of 34
  1. #21  
    I gave up on SMS. Never having used it much, I used it once for some pretty important notifications to fellow employees last month. It was a time when the SMS was down. IMHO either offer a service that's up all the time or don't offer it at all. Finnish school children have been using SMS for years. I listened to an interview with a VZ CEO a couple years ago where he was excited about offering SMS. SMS isn't some new thing that just came out yesterday. If it isn't rock solid now? Forget about it. Email works for the people that actually check their email or voicemail for the folks who religously never answer their dang phone.
    David
  2. #22  
    Originally posted by drw
    If it isn't rock solid now? Forget about it.
    I'm gonna pull a Dan and respond to my own message. So, would you buy a car whose air bags and anti-lock brakes only worked some of the time? Didn't think so. SMS is a lost cause, to be put on the shelf next to bluetooth to collect dust and maybe look at it again in a couple a years. Universal Wireless USB is what I'd like to see. Or at least Firewire 800 since my data is crowding out my apps on the laptop. By the time they get SMS working bullet proof mission critical, it will be "sooo 5 minutes ago".
    David
  3.    #23  
    Originally posted by drw
    IMHO either offer a service that's up all the time or don't offer it at all.
    I highly disagree. I would MUCH rather have a feature that gives me near-instant "push" notifications of incoming emails 90% of the time, slow notifications 5% of the time, and no notification the other 5% of the time (not sure what the actual figures are), than to not have such an option at all.

    However, if the overall SMS functionality were as unstable as Sprint's http://messaging.sprintpcs.com/sml/guestCompose.do gateway, I'd likely be more down on it. Earlier today I was again getting the "One of the message recipients does not subscribe to this messaging service." error for awhile, and then a few minutes ago I tried to visit the page and I got the following:

    Error 404--Not Found


    From RFC 2068 Hypertext Transfer Protocol -- HTTP/1.1:

    10.4.5 404 Not Found

    The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent.

    If the server does not wish to make this information available to the client, the status code 403 (Forbidden) can be used instead. The 410 (Gone) status code SHOULD be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable and has no forwarding address.
    Now, quoting RFCs in your error message is certainly cute, but not quite cute enough to excuse all these screw-ups.

    SMS isn't some new thing that just came out yesterday. If it isn't rock solid now? Forget about it.
    I gather that it's closer to being rock-solid on GSM networks, for which the protocol was originally invented (actually, I'm not sure the protocol used for "One-Way Messaging" (Sprint's official name for it) even is SMS...).

    I'm gonna pull a Dan and respond to my own message.
    LOL.
  4.    #24  
    I've just made an important update to sms_biff. Anyone out there who's using it should upgrade to the latest version.

    I realized that the SMTP envelope From forging behavior (which is necessary since Sprint's email-to-SMS gateway doesn't look at the From: in the message header) was causing bounce messages to get spammed out to the people sending you mail, if Sprint's server was temporarily down.

    Along with upgrading to the new version, you should change your .procmailrc (or equivalent) to use this setting, if it isn't already:

    Code:
    sms_biff_SMTP_SERVER = mx.messaging.sprintpcs.com
    There's a new variable called sms_biff_FORGE_ENVELOPE_FROM whose default setting of "auto" will cause forging to be done only when you're directly using Sprint's MX server. This is the only time it's safe, since any failures will be detected immediately, unlike if you use your own SMTP server, in which case multiple delivery attempts may be made, accompanied by non-delivery notifications to the envelope sender.

    Update: I also added the ability to specify sms_biff_SMTP_SERVERS (plural) and set it to a comma-separated list of servers to try, in order.
    Last edited by Dan Harkless; 09/16/2003 at 04:08 AM.
  5.    #25  
    Just made a small update to sms_biff. I discovered that if the Lingua::EN::Keywords module can't find enough keywords, it'll return a list containing trailing 'undef's, which would cause a warning in your procmail log. keywords() is broken for doing this, but I've added a workaround to sms_biff.

    I also noticed a problem that was causing much more voluminous warnings in the procmail log. Again, it's a module bug, this time in Lingua::EN::Tagger, which is a prerequisite of Lingua::EN::Keywords 2.0.

    If you've seen warnings like:
    Use of uninitialized value in pattern match (m//) at /usr/lib/perl5/site_perl/5.8.0/Lingua/EN/Tagger.pm line 935, <STDIN> line 92.
    in your procmail log, the only current solution is to downgrade from Lingua::EN::Keywords 2.0 to 1.3, which is luckily still available on CPAN.

    That's a good idea anyway, due to bugs in Lingua::EN::Keywords 2.0 that cause it to have kind of a screwy idea of what a keyword is (i.e. it can contain spaces, may be made up entirely of non-word characters, and the same word may appear in multiple keywords).

    I've sent bug reports to the authors of Lingua::EN::Keywords and Lingua::EN::Tagger, so hopefully in the future it won't be necessary to limit yourself to version 1.3 of the former.
  6. #26  
    or sign up for free on www.email2sms.com.my
  7.    #27  
    Interesting. Hadn't heard about them.

    They seem to be doing this from a commercial perspective -- I wonder what their business model is. Gain critical mass of users and then start charging? Or retain this as a free service to entice users to other pay services to be offered in the future...?

    In any case, there's no way in hell I'd hand over the passwords to my accounts to some random Malaysian company. Even if I had reason to trust them not to abuse the info, I'd have no way of knowing how well-designed their security is, to prevent hackers from breaking in and getting all the users' account passwords.

    My first impression of their security isn't too good. Their subscribe page requires you to send your email account's password to them in a non-SSL-encrypted form. The submit button is called "Send Email", meaning your password makes additional cleartext hops, unless the email gets sent to and processed on the same machine the webserver's on.

    Also no mention of POP3S, APOP, or other POP3 encryption standards in their FAQ, so I presume they only support garden-variety cleartext POP3.

    Anyway, thanks for the tip. Good to know what else is out there.
  8. #28  
    Originally posted by Dan Harkless
    Interesting. Hadn't heard about them.

    They seem to be doing this from a commercial perspective -- I wonder what their business model is. Gain critical mass of users and then start charging? Or retain this as a free service to entice users to other pay services to be offered in the future...?

    In any case, there's no way in hell I'd hand over the passwords to my accounts to some random Malaysian company. Even if I had reason to trust them not to abuse the info, I'd have no way of knowing how well-designed their security is, to prevent hackers from breaking in and getting all the users' account passwords.

    My first impression of their security isn't too good. Their subscribe page requires you to send your email account's password to them in a non-SSL-encrypted form. The submit button is called "Send Email", meaning your password makes additional cleartext hops, unless the email gets sent to and processed on the same machine the webserver's on.

    Also no mention of POP3S, APOP, or other POP3 encryption standards in their FAQ, so I presume they only support garden-variety cleartext POP3.

    Anyway, thanks for the tip. Good to know what else is out there.
    From the company:

    There are currently no plans to charge for the service. It is free
    indefinately. Your information is not shared with ANYONE. It is maintained at our database and stays there only. Would be great if you recommended our service to your friends and family.

    I like the service a lot. Very handy. Email privacy isn't a big concern to me, though.
  9. #29  
    Sprint changed thier email to SMS gateway for better. Saw ^LiMiTinCrEaSed^ this morning. Apprently Sprint upgraded some of their server. I did some experimentation, and it seems that we can now get almost all 160 characters (157 to 159 in my tests).

    Sprint is now sending full From: and Subject: headers, but they don't reserve space for the subject anymore, if it's not present.

    Time to reconfigure sms_biff to take advantage of this. :-)

    PS. question for Dan, any progress on MIME filtering?
  10.    #30  
    Originally posted by goobar
    Sprint changed thier email to SMS gateway for better. Saw ^LiMiTinCrEaSed^ this morning. Apprently Sprint upgraded some of their server. I did some experimentation, and it seems that we can now get almost all 160 characters (157 to 159 in my tests).

    Sprint is now sending full From: and Subject: headers, but they don't reserve space for the subject anymore, if it's not present.

    Time to reconfigure sms_biff to take advantage of this. :-)
    Cool! Good catch, goobar. I hadn't gotten a ^LiMiT InCrEaSeD^ mail yet, and had been too busy to investigate why in the Inbox application of my G1000 (perhaps to be replaced with a Treo 600 soon), the line terminator character on Sprint's pseudoheader lines was now appearing as a square box (i.e. illegal character) in the folder view, and was completely invisible (i.e. no newline) in single-message view. I did notice yesterday that SMSes stopped flowing for a few hours in the afternoon (first time in quite awhile I've noticed this happen) -- presumably they were doing testing of the new software at this time.

    I did some additional research (I find that it's possible to get all 160 characters), and have modified sms_biff and the sample .procmailrc file appropriately.

    Thanks very much for bringing this to my attention!

    PS. question for Dan, any progress on MIME filtering?
    Alas, no. I have been insanely busy (I'm glad Sprint rolled out this change today -- almost exactly one year after their last major change to the email-to-SMS gateway functionality, incidentally -- had it been a bit earlier I would not have had time to make this fix). Things are calming down somewhat now, and I'll try to get to this as soon as I can, but unfortunately I have a bunch of higher priority to-do items in front of it in line.
    Last edited by Dan Harkless; 01/22/2004 at 05:16 PM.
  11.    #31  
    Quote Originally Posted by Dan Harkless
    Quote Originally Posted by goobar
    PS. question for Dan, any progress on MIME filtering?
    Alas, no. I have been insanely busy (I'm glad Sprint rolled out this change today -- almost exactly one year after their last major change to the email-to-SMS gateway functionality, incidentally -- had it been a bit earlier I would not have had time to make this fix). Things are calming down somewhat now, and I'll try to get to this as soon as I can, but unfortunately I have a bunch of higher priority to-do items in front of it in line.
    Well, it only took a year , but I finally found some time to implement MIME parsing in sms_biff.

    It's much nicer now -- it'll correctly prefer the text/plain part over the text/html part in multipart/alternative emails, and just generally does the right thing (though it's currently limited to taking text from a single part of the mail, even in those rare cases where there'd be room within the 160 characters for text from mutiple successive parts).

    I have also implemented two new built-in filters for the mail body, "elide_quoted" and "rm_pgp". elide_quoted abbreviates blocks of '>'- or '|'-quoted text and the neighboring attribution line as the string ">...". rm_pgp removes inline "PGP SIGNED MESSAGE" headers.

    With this new functionality, it's no longer necessary to lean on the "keywords" and "summarize" filters to get useful output from MIME-encoded mails (and top-quoted reply mails), and it's preferable not to use them since for most mail, a truncated prefix of the (MIME-decoded) body (or Subject) does a better job of informing what it's about. Therefore I have changed the settings for sms_biff_FILTER_BODY and sms_biff_FILTER_SUBJECT in my own .procmailrc to no longer use those filters. I'm now using the new default setting for sms_biff_FILTER_BODY, "elide_quoted|rm_pgp", and for sms_biff_FILTER_SUBJECT I'm using "rm_ws,SqueezeText,SqueezeText|rm_ws" (the new default is "rm_ws").

    Full details on the new functionality are in sms_biff's comment header. Let me know if you have any problems. Note that you will need to install the MIME-tools Perl module collection if you do not already have it on your system. Enjoy.
  12. #32  
    I'm a linux newbie. I've managed to set up a Debian server running Postfix and Courier-IMAP w/virtual domains by following some handholding step-by-step guieds I found on the web, definitely not by understanding exactly what I'm doing. So I'm far from sure that I understand how I would graft this script onto my setup in order to send the SMS to my Treo that I could use to trigger an IMAP sync.

    Can anybody help this poor noob?

    TIA,

    Seth Green
  13.    #33  
    Quote Originally Posted by 35whl21
    I'm a linux newbie. I've managed to set up a Debian server running Postfix and Courier-IMAP w/virtual domains by following some handholding step-by-step guieds I found on the web, definitely not by understanding exactly what I'm doing. So I'm far from sure that I understand how I would graft this script onto my setup in order to send the SMS to my Treo that I could use to trigger an IMAP sync.

    Can anybody help this poor noob?
    I don't use Postfix or Courier-IMAP, but doing some searching, it looks like the Postfix + Courier-IMAP + procmail combination should work just fine.

    Create a ~/.procmailrc file, using my sms_biff.procmailrc as a guide (you'll have to tweak the sms_biff_* variables to be appropriate for your particular cell provider -- see the documentation in sms_biff's header for the details).

    Because your mail server programs use Maildir rather than mbox format, you'll need to add these lines to the top of the .procmailrc:

    MAILDIR=$HOME/Maildir/
    DEFAULT=$MAILDIR
    Now, if you only want to use procmail on your account, not on others on the system, do this while logged in as your account (note those are double quotes inside of single quotes):

    % echo '"|/usr/bin/procmail -t"' > ~/.forward
    If you want Postfix to automatically check for a .procmailrc when delivering to any user, without a .forward file having to be there, then instead use these instructions in the Postfix FAQ.

    You should now be set!

    BTW, while looking into this for you, I discovered an issue with how the sms_biff_SMS_EMAIL_ADDRESS and sms_biff_SMTP_SERVER documentation was worded (for non-Sprint users). If you've already downloaded sms_biff, you may wish to re-download it to get the updated docs.
    Last edited by Dan Harkless; 12/04/2005 at 08:34 PM.
  14.    #34  
    Dunno if anyone is using it besides me, but I finally managed to set aside some time to update my sms_biff companion script TreoVisorCentral_notification. The new version is called treocentral_wmexperts_notification. It drops support for visorcentral.com (where new posts are now no longer allowed), adds support for wmexperts.com, adds support for rewriting the notification emails that sometimes randomly come in pointing to forum.smartphoneexperts.com, and adds support for the latest notification email format (including preserving PM subjects in the body).

    [Hmm, I see that this forum has been recategorized / renamed to Palm OS Software > Palm OS Communication, which is not appropriate for sms_biff, since it runs on the server side and is equally usable with Palm OS and Windows Mobile devices. I don't see a better forum for the thread to be moved to, though, since there's no cross-platform software one. I suppose the closest would be "Cross-Platform Chat", though the forum description says it's for religious platform flamewars and the like, which would seem like an inappropriate and very unfortunate place to dump this thread into.]
    Last edited by Dan Harkless; 08/01/2008 at 02:25 AM.
Page 2 of 2 FirstFirst 12

Posting Permissions