Page 1 of 3 123 LastLast
Results 1 to 20 of 46
  1.    #1  
    Interesting. Starting today, if someone emails you at yourphonenumber@messaging.sprintpcs.com, the SMS message will start with their email address, a colon, and a space.

    Specifically, it uses the "envelope sender" from the SMTP transaction -- it ignores whatever email address is in the email's From: header (usually those two'll be the same).

    This is a good development for people who get raw emails sent to their SMS email address, but it kind of sucks for my sms_biff program, since some of those precious 160 SMS characters are now being used up by a needless indicator that the SMS notification was sent from your email account. (I went on a wild goose chase thinking something was wrong with my sms_biff script until I realized that it was Sprint adding this new text. )

    I guess I'll modify sms_biff to (optionally) forge the envelope From as being from the sender of the original email, and leave out the "F:" line that currently contains that information.
  2.    #2  
    Oh, and I guess I'll probably abandon that planned feature I had of having sms_biff use http://messaging.sprintpcs.com/ and do a mapping of email address to caller ID phone number. Now the email From address is always going to be there whether one wants it or not -- can't omit it to save message space as with sms_biff's F: line (although you can minimize the space it takes by forging the email address as being from, say, "a@b.c").

    Speaking of Sprint's web SMS interface, they haven't added a way to include this new email From info. So either you can use the email -> SMS gateway and identify yourself via email From or you can use the web -> SMS gateway and identify yourself via caller ID.
  3. #3  
    Although I don't understand half of what you said... ;-)

    But since I use Yahoo email and I have it send email alerts to my Treo I now see "y-alerts@yahoo-inc.com:Fr: (email address)

    This takes up about the first 1/2 of my allowed number of characters. It is rather annoying. Is there anything we can do about this? (those of us who don't know programming?)
  4.    #4  
    Originally posted by Llynx
    Although I don't understand half of what you said... ;-)

    But since I use Yahoo email and I have it send email alerts to my Treo I now see "y-alerts@yahoo-inc.com:Fr: (email address)

    This takes up about the first 1/2 of my allowed number of characters. It is rather annoying. Is there anything we can do about this? (those of us who don't know programming?)
    No, think you're out-of-luck if you don't have the ability to install software like sms_biff on a mail server you have control over. You could complain to Sprint and ask that they add a web-configurable option to your account to let you turn off the new added From info, but I'd be surprised if they'd implement this.
    Last edited by Dan Harkless; 01/23/2003 at 07:23 PM.
  5. #5  
    Oh welllllll ... no mail server ... no laundress ... no housekeeper ... story of my life.
  6.    #6  
    Huh. Either they've now made another change, or I just neglected to test this earlier today (probably the latter) -- Subject lines now also get automatically put into SMS message bodies, in the same format as From: lines.

    So if the following email is sent:

    From: "Some Body" <dude@somewhere.com>
    To: yournumber@messaging.sprintpcs.com
    Subject: Hi!

    Hey there.
    you'll receive this SMS message:

    From: No Caller ID
    Date: date and time
    dude@somewhere.com: Hi!: Hey there.
    So looks like I can turn off the "S:" line in sms_biff by default as well. Now two of the main reasons I wrote sms_biff (rather than using brute forwarding of incoming mails to the SMS address) are gone, though the masquerading of the envelope From, which I'm adding right now, will still be very useful.
  7.    #7  
    BTW, Sprint's email -> SMS gateway automatically crops the From: and Subject: header content to 32 characters each when sticking them in the SMS body. I guess this is one place where sms_biff could still be useful to some -- if you need to be able to read subject lines beyond the 32nd character, you'll be able to tell sms_biff to make its own "S:" header in the body at a maximum length of your desire, rather than setting the Subject: header and letting Sprint do its own thing.

    Noticed during this testing that if you have long strings without spaces, characters can get partiallly or fully (in the case of skinny characters like ':') chopped off on the right edge of the SMS notification popup window (no problem when viewing the messages in the actual SMS application, though).
  8. #8  
    Originally posted by Llynx
    This takes up about the first 1/2 of my allowed number of characters. It is rather annoying. Is there anything we can do about this? (those of us who don't know programming?)
    Ugh.. I hate when corps do crap like that. I was just about to start work on a small information exchange via SMS. They're going to whittle it down to where our message can be "hi " or "me too." and that'll be 160 chars.
  9.    #9  
    Originally posted by potatoho
    Ugh.. I hate when corps do crap like that. I was just about to start work on a small information exchange via SMS.
    Well, yeah, it kinda sucks for us technically savvy folks, but arguably it was done for the greater good, since most users don't have the ability to install special software to propagate email headers into their SMS message bodies.

    They either have their accounts set up to brute-forward a copy of their incoming emails to their SMS address, or they have correspondents send them original emails to their SMS address. In either case, it was sucky prior to Sprint's changes, since vital From: and Subject: info was stripped away.

    By the way, I've now made the above-discussed changes to sms_biff to get it to play well with Sprint's modified system. Most notably, it now forges the address of the sender of the original email in the SMS email, so there's no more space-eating double From.
  10. #10  
    Originally posted by Dan Harkless
    They either have their accounts set up to brute-forward a copy of their incoming emails to their SMS address, or they have correspondents send them original emails to their SMS address. In either case, it was sucky prior to Sprint's changes, since vital From: and Subject: info was stripped away.

    Bravo.....I was one of those who, after migrating to 3G, noticed this very annoying omittance of the header information from incoming pages. Since some 50 or so people have my pager number as (mynumber)@messaging.sprintpcs.com, the fact that, prior to this change, I had NO IDEA WHO THE HECK WAS PAGING ME, was one of the biggest inconveniences of the 2-3G migration. It was such a huge issue for me, I was considering downgrading back to 2G and bringing my Samsung I300 out of retirement.

    I do feel that Sprint will eventually correct the issue that you guys seem to have but until then, AT LEAST those of us without access to the programming that you are speaking of, will know who our pages are coming from.

    Kimberly
  11. #11  
    So, Kimberly, you've stuck with the Treo? I was following your thread on the I330 board and thought you'd bailed on us. After all, the Treo does not have the beloved top display of the I300
  12. #12  
    Originally posted by Brooose
    So, Kimberly, you've stuck with the Treo? I was following your thread on the I330 board and thought you'd bailed on us. After all, the Treo does not have the beloved top display of the I300
    Yep, Broose, I stuck with the Treo.

    I still have hi hopes for a top display on the I500, tho!!!

    Glad to see a familiar face around here.

    Kimberly
  13. #13  
    Originally posted by Dan Harkless
    No, think you're out-of-luck if you don't have the ability to install software like sms_biff on a mail server you have control over. You could complain to Sprint and ask that they add a web-configurable option to your account to let you turn off the new added From info, but I'd be surprised if they'd implement this.
    Dan,

    I'm taking a look at your sms_biff stuff and it looks great. I'm currently using spambouncer on my server and would like to slide sms_biff into the already existing .procmailrc for only emails that pass as valid.

    These lines are in the the .promailrc for an email successfully pass

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

    Can you tell me the best way to insert the lines:


    :0 c
    *$ !^$X_LOOP
    | sms_biff

    Thanks
    Phil
  14. #14  
    By the by.. you guys should consider using something like stripmime.pl if you want to make nice compact emails. It strips attachments etc and all the happy MIME stuff, as well as a pretty crappy html conversion if no plain-text exists.

    http://www.phred.org/~alex/stripmime.html
  15.    #15  
    Originally posted by nchargreed
    Bravo.....I was one of those who, after migrating to 3G, noticed this very annoying omittance of the header information from incoming pages. Since some 50 or so people have my pager number as (mynumber)@messaging.sprintpcs.com, the fact that, prior to this change, I had NO IDEA WHO THE HECK WAS PAGING ME, was one of the biggest inconveniences of the 2-3G migration. It was such a huge issue for me, I was considering downgrading back to 2G and bringing my Samsung I300 out of retirement.
    Hmm, are you sure you mean "paging"? If someone leaves you a page via the voice mail interface, it uses the Caller ID field of the SMS to indentify them, and that didn't change, did it?

    I do feel that Sprint will eventually correct the issue that you guys seem to have but until then, AT LEAST those of us without access to the programming that you are speaking of, will know who our pages are coming from.
    Well, there isn't really an "issue" to "correct" -- it's just that they've added features to the email-to-SMS gateway. If people want to send SMSes that don't contain an email From: address, they can always use the http://messaging.sprintpcs.com/ web-to-SMS gateway.
  16.    #16  
    Originally posted by philipgood
    Dan,

    I'm taking a look at your sms_biff stuff and it looks great. I'm currently using spambouncer on my server and would like to slide sms_biff into the already existing .procmailrc for only emails that pass as valid.

    These lines are in the the .promailrc for an email successfully pass

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

    Can you tell me the best way to insert the lines:


    :0 c
    *$ !^$X_LOOP
    | sms_biff

    Thanks
    Phil
    Phil, I'm not a procmail expert, but there's some stuff going on there that I haven't seen before, like the manually appending to the mailbox with ">>" rather than delivering to it, as is usual. Since you don't include the spambouncer (which I'm not familiar with) lines, it's hard to visualize what the rest of your .procmailrc looks like, and thus where you need to stick the sms_biff call.

    It looks like now, though, that you're delivering mails only on successful match of certain factors, and then bouncing them as the last, default, case. Because the sms_biff call needs to be its own recipe, with the 'c' there to make it operate on a copy of the mail, I suspect you need to reverse the logic of your .procmailrc. You'd need to change it to first reject mails based on various factors (spambouncer, or formail header checks as above) and then make the default case be to deliver the mail. Then just before that delivery recipe, add the ":0 c" sms_biff recipe.
  17.    #17  
    Originally posted by potatoho
    By the by.. you guys should consider using something like stripmime.pl if you want to make nice compact emails. It strips attachments etc and all the happy MIME stuff, as well as a pretty crappy html conversion if no plain-text exists.

    http://www.phred.org/~alex/stripmime.html
    Thanks, potatoho. I was planning on using Perl MIME-munging modules to do that directly from sms_biff, but if they're missing any functionality that I need, I'll take a look at the external script approach with stripmime.
  18.    #18  
    Originally posted by Dan Harkless
    Thanks, potatoho. I was planning on using Perl MIME-munging modules to do that directly from sms_biff, but if they're missing any functionality that I need, I'll take a look at the external script approach with stripmime.
    I looked at stripmime, as well as similar scripts demime and mimefilter, and none of them had the features I want (for instance, none of them decodes quoted-printable -- actually I think one did but it didn't do it properly).

    Therefore I'll indeed be using the MIME-tools module collection (which unfortunately looks to have a bit of a learning curve) when I get a chance to implement this.

    Looks like it's even more important now than it was in the past to get this working, though. In response to some claims in the "Sending TREO SMS limited to 20 characters?" thread, I did some testing, and I see that SMS message "bodies" are now limited to 91 characters, rather than the old 160.

    The way the 91 character limit comes about is because Sprint's stupid software unconditionally reserves the space for the new From: and Subject: headers. The content of those headers is truncated at 32 characters, and each is followed by ": ", so 32 + 2 + 32 + 2 + 91 = 159. Not sure where the 160th character went -- it may be a newline or NUL terminator at the end of the message.

    Regardless of whether you use the full 32 characters of those headers (or whether you have a Subject: at all), the full 68 characters get deducted from the maximum body length and you only get the 91 characters max.

    This is really lame.

    It also happens even if you use the http://messaging.sprintpcs.com/ web SMS gateway. They've made a recent change where messages sent from that now get a From: header, "ANONYMOUS@messaging.sprintpcs.co: ". Pretty dorky that they chose an email address that exceeds their own 32-character limit.

    Anyway, it's not possible to make a Subject: header using the web interface, but nonetheless, they deduct the full 68 "potential" header characters and bodies of SMSes sent via the web are also limited to 91 characters.

    It's really bogus that the "characters remaining" JavaScript-updated field on the web SMS form hasn't been updated to reflect the new, stupid 91-character limit.

    We can only hope they haven't updated it because they intend to smarten up their software and get it to dynamically calculate the maximum body size given the space actually used by the From: and Subject: headers (gee, that's real hard to implement...). I won't hold my breath, though.
  19. #19  
    Originally posted by Dan Harkless
    ..none of them had the features I want (for instance, none of them decodes quoted-printable -- actually I think one did but it didn't do it properly).
    A program called, emil, does lots of charset conversion and repackaging of attachments. It can help to normalize messages.
  20. #20  
    Originally posted by nchargreed


    Yep, Broose, I stuck with the Treo.

    I still have hi hopes for a top display on the I500, tho!!!

    Glad to see a familiar face around here.

    Kimberly
    I'm also "stuck" with the Treo, but unlike Kimberly I'm going to the OTHER side of the tracks and getting a Kyo 7135 when Sprint or Verizon FINALLY releases it. I'm just glad I got my Treo back in late October instead of believing that the 7135 was right around the corner............. (yeah, if you lived in freaking Australia!).

    And on the SMS thing... are a lot of you having to pay for additional bundles of SMS's to cover all of the e-mail notifications?
    Robert
    Please visit my moblog, Robert-O-Rama
Page 1 of 3 123 LastLast

Posting Permissions