I think the consensus is to go with the "big blob of text" approach. You mentioned that postal workers are the only people qualified to parse addresses—let them do it. The validation done on your end shouldn't be much more than asserting that addresses contains non-whitespace characters.
I don't know how well this works in practice, but it's the most "correct" thing to do.
Name of recipient, state/province/etc., postal code and country, maybe. But for the rest, that bit (at least in the UK) that goes in the middle... what policing can you do? That part is just a text blob. You can't do much meaningful with it except for showing it to somebody (e.g., on a label affixed to the package you're sending) and have them figure it out.
Well sure, once you've separated name and country and postal code you've already pulled out most of the data.
The blob has been tamed to 1-2 lines, and you're probably best off giving 'line 1' 'line 2' 'line 3' fields. At this point the chance of confusion is minimal, even if you can't validate very well.
make sure its valid text - make sure you handle all the high asci characters and do something sensible with non Latin text.
I once spent the best part of a day tracking down a problem with a single bad address for a major UK directory some how some one had entered an address in Egypt in Arabic.
As soon as you don't control the whole thing end-to-end, i.e. from the user entering the data to printing it on an envelope: it won't work at all. It would require every program in the whole chain to accept this "big blob", which is simply not going to happen.
I can understand not validating fields, but users are hopeless and like guidance. Giving them some structure in address fields helps the user through the system.
I don't know how well this works in practice, but it's the most "correct" thing to do.