Ah, lovely web automation! :-)
So, lately had a little mini-project to give myself.
AT&T's "Unified Messaging" (voicemail). Wanted to "cut the cord" -
bye-bye landline - porting ye olde landline # to mobile.
But first, wanted to download all of my content from
AT&T's "Unified Messaging" (voicemail).
AT&T's "Unified Messaging" (UM/um), in addition to ye olde phone DTMF
("Touch Tone") interface to the voicemail, also has web interface.
So, web interface. Essentially works as web GUI interface to email in
"INBOX", messages are stored in email, and within an email item,
voicemail as .wav attachment, text attachment having transcript as body
- which will generally have empty body if it wasn't able to transcribe
it. And generally html attachment, an html version of that text
attachment.
And, "of course", Perl also has the lovely WWW::Mechanize.
So ... I got to programming. mitmproxy was also handy to figure out
some bits going on within the SSL/TLS communications between client
(e.g. web browser) and AT&T server(s).
And got the key bits of that finished up
this past Sunday. And got 'er all nicely downloaded.
$ um.att.comum.att.com: Inbox is empty. Exiting
$
That's what it outputs at the end, when there's nothing left to
download.
It also handles deleting the "email" item (message and related) from the
AT&T "INBOX" once it's successfully downloaded.
$ cd ~/.um.att.com.d/data
$ ls -A1 | sed -e 's/^.*\././' | sort | uniq -c | sort -k 1,1bnr -k 2,2
117 .eml
117 .wav
113 .txt
112 .html
$
Very nicely handles it all.
.eml is the full raw "original" email as AT&T has it in the "INBOX",
.wav files are the raw audio portion thereof,
.txt the text transcript (or no file if that part was empty), and
.html the html equivalent of that text.
Ah, I was wondering about why one less .html than .txt ... peeking
further, the .txt has:
Message too short for transcription
And that original .eml has no html part, and the .wav ... yeah, no words
in that audio.
Alas, I didn't clean out quite all the junk before downloading
everything ... and the slight mismatch makes that bit of
junk pretty easy to spot ... likewise grep on the .txt files is rather
handy.
So, the file names start with ISO date and time, which is derived from
the Date: header which is timestamp of when the end of the message was
received. Likewise that same time data is used to set the mtime on the
files. File names also contain data from Subject: and From: fields,
generally identifying caller name/number, or when not (CNID) identified
otherwise unknown caller / Identity Withheld, e.g.:
... unknown caller ... Identity withheld <unknown_caller...>
https://www.mpaoli.net/~michael/bin/um.att.com
Ah, one of these days I need to tweak Apache configuration so it
"knows", e.g. that file (and that name and location), can be handled
like plain text, not a binary. Yeah, I know there's a "magic" type
option that can read the files and make intelligent guess on that, but
that's excessive overhead for most cases - so really need to just
configure the exceptions ... down to directory or even per-file basis.
(On my to-do list ... with thousands of other items yet to be done ...
at least maybe when I get around to it).
And ... maybe even others might find it handy, or handy starting point.
Though this one was done almost / mostly as a one-off/one-shot.
Though until the number completes being ported over, very handy to still
check if anything has shown up there, and download it if so.
It might need some adjustments to handle some other email messages.
E.g. the ones from AT&T about the INBOX being nearly full. And looks
like I probably won't have need for that (nor example data to match it
to and test it on). And I didn't handle the more general email case
(which I think UM will also accept and have in "INBOX"), as I only ever
used UM for voicemail.
Now +Web interface:
https://www.digitalwitness.org/
On Thu, Oct 31, 2024 at 12:12 AM Michael Paoli via BALUG-Talk
<balug-talk(a)lists.balug.org> wrote:
> ---------- Forwarded message ----------
> From: Michael Paoli <michael.paoli(a)berkeley.edu>
> To: BALUG-Talk <balug-talk(a)lists.balug.org>
> Date: Thu, 31 Oct 2024 00:11:26 -0700
> Subject: [BALUG-Talk] Announcing digitalwitness.org - free public signing (witnessing) service
> Announcing digitalwitness.org - free public signing (witnessing) service
> At present it's in open/public Beta.
>
> At present the ssh interface is open, other(s) (most notably web) will
> likely follow in time.
>
> Let's say you have a (possibly) large digital artifact (or archive file
> of such items). Or even possibly much smaller item. Suggested approach
> is to get secure hash/digest of the item, e.g.:
> $ sha512sum digital_artifact_file
> 3ddd987f33a96b50777d15f7850d80d8e30badf12501289d28d5ee4857d62c25c2c700b6a1313cace8b128fe1e4d1ff4787d70c46e1f633e5e4589bf3f2343ba
> digital_artifact_file
> $
> Then get that hash/digest signed, e.g.:
> $ ssh -nT digitalwitness(a)digitalwitness.org --
> 3ddd987f33a96b50777d15f7850d80d8e30badf12501289d28d5ee4857d62c25c2c700b6a1313cace8b128fe1e4d1ff4787d70c46e1f633e5e4589bf3f2343ba
> -----BEGIN PGP SIGNATURE-----
>
> iQIzBAABCgAdFiEEEMoY7NqvKKtE7xkCOAS8z7K+pwUFAmcjEtkACgkQOAS8z7K+
> pwWH3A//cDtGIHokwF+GEvKnFFE+Cw2hiPVTe0PkBPuymGnLPAC9Um7YkVt1vP8u
> ZZhGOVrAivFV75gVASszq6Au4OKY/2GOO0+SMkVaxd9VzprxBH+j8BVixGiDvU3L
> k9JbSzzLIKNoTpPptWbphPoEO6cE4WSm1HubMFeODE7znQeVfk5UlpIEE/7XcT0r
> lmwnUaoSwhZUL5HxWE3Pt6x4QSTOin38DHCS55LRfDwHC5og5fc7eiC9TSqr/kVB
> goyxYg/lCNrKa7HQto03zJ2ZctZnsNj5n81WhPYzBwlpGfb1T/3htqP17PCLJ19W
> amWC+kn+9vR5cwGwuEnBxfOlE//CI7d3gWXSSsvHCDhX49Drh1m7OIw4I9vnYYcV
> h9fgajSR1SAMiQwo7uQjrmByZnUdXCTfRJ6ywBfuKaZdBX1Y+AGD8cUWc5qnCwrR
> rX4bznL2JZhrwrNh6abmDcyqRzMmXr+jM7WqZiJbcxkhoJZ78c+UtCR6ETreVui0
> Ah7a7HSAuZ6E3dek1oBzA5zTV/bpZHEcdz8UcRYWryEF7wtzJ0gi4SXsWLLGq/LA
> LaSOPgcA8KMB3A5NtSYdn0ax/MEao/r/spNrxiQI5jKTYBuoI3qSA7I8Pp1qIkkY
> DS/XHzT2CNVw6T/YxvqrhqvSPfaQkQWy0lse6WVIG3CfW7Bp0Pk=
> =5mCo
> -----END PGP SIGNATURE-----
> $
> For more information, help, public signing key, etc., just run without
> any "command" or arguments thereof, e.g.:
> $ ssh -nT digitalwitness(a)digitalwitness.org
> And that will provide one with much relevant information, and including
> important details (e.g. the signed data is signed without first adding
> any implicit newline on the end, though one can explicitly provide that
> if desired).