seeing SRS0 in email from field

I am an end-user, rather than an email or system admin, but I have a 
decent understanding of smtp, a little understanding of spf, and a 
SLIGHT understanding of srs. One thing thats not clear to me in the SRS 
explanations is whether the end user should ever see the rewritten 
return path in the from field, and, if not, does it depend on some 
system to remove or hide it.

The reason I ask is: I get a fair amount of email at my Verizon wireless 
SMS (text message) cell phone address - alerts from different sources, 
notification of work assignments, etc. And some of them come in with a 
weird email address - for example: 
[email protected]. Generally, 
these get forwarded to my phone from other addresses I use - I don't 
remember exactly how this example was routed, since I have changed a lot 
of things to try to get rid of this, and to solve some non-delivery 
problems.

When I asked Verizon Wireless if they were familiar with SRS, and 
whether they have implemented support for it - or if I was seeing this 
because they had not, or because of a bad header from the sender 
perhaps, their answer was "Verizon Wireless does not implement 
anti-'spoofing' technology for use with our devices. In addition, we are 
only able to provide information regarding features that are currently 
available from us." Basically, a non answer.

Now, a newer message from the same source showed up correctly on my 
phone. I don't think I changed anything in the routing - perhaps Verizon 
did change something. And I should mention that I cannot see headers on 
the SMS messages, so its hard to figure out whats going on.

But, my basic question is: should an end user ever see this kind of 
address - can any of the scenarios of support or non-support in a 
forwarding chain cause this - or is it dependent on the final receiving 
system to hide these? Or is this normally only shown in smtp headers 
that a user normally does not see?

Thanks
Dan Kronstadt
Shadow Hills, CA
Are you getting all your email? Free monitoring at 
http://www.shserve.com/emailmon