Mail::Webmail::Gmail has a date of 2006 on it. I'm going to guess that a 16 year old module probably isn't compatible with Google's current implementation of webmail. And yes, any modern "web" module should just depend on LWP::UserAgent and not have a direct dependency on SSLeay. (with the exception of event-driven modules which often have to re-invent things themselves)

Ok, and thanks for your reply. I don't know how to say it in the language of perl modules, but I think it's clear that Google is shutting the door on the type of access that Mail::Webmail::Gmail provided before the free service became a magnet for bad actors. If I were putting up the sign it would say:

STOP. Here swirls Charybdis. Do not play this logic game.

If you want to inspect a Gmail mailbox, you can currently go into Google settings and enable "insecure" protocols (for i.e. IMAP and SMTP) and then use Perl's IMAP modules to interact with the mailbox. This support is supposedly going away some time, but works for now. I don't know if there is a native API client for Google's mail back-end, in Perl.

Let me again repost what I discovered upthread from google:

To help keep your account secure, starting May 30, 2022, 
Google will no longer support the use of third-party apps or devices w
+hich ask you to sign in to your Google Account using only your user n
+ame and password.

[download]

Regarding what back ends there might be, my strong suspicion would be that you will be able to do this if you're a paying client. At least that's what I read into the following paragraph

Please note this deadline does not apply to Google Workspace or Google Cloud Identity customers. The enforcement date for these customers will be announced on the Workspace blog at a later date.

I'd be curious if someone among us had experience with either Google Workspace or Google Cloud Identity. I do not. My guess is that they might have backends for perl access, but the landscape is changing so fast. A lot of people's stuff is gonna break down at the end of this month. And it's not just gmail, it's anything without a subscription, as far as I can tell. I clicked around a bit to see what was still out there,and I fear that this type of access to gratis webmail is going the way of the dodo.

When you configure the outgoing SMTP host, you need to first make sure that that host is actually running an SMTP server. "fourth" looks like the host name of your raspberry Pi, so you should first make sure you installed Postfix correctly. But also, if you installed postfix locally, then you can deliver mail directly to postfix without using SMTP at all, and test this from the command line using the 'sendmail' or 'mail' commands. Also, using SSL from a local service to a local service is unnecessary complication. SSL needs a certificate, and it won't match for the local host name, forcing you to also set flags to disable host name checks.

Now that I'm halfway through this thread, I'd like to refine the task I'm doing to be one where I'm sending an email from my rpi to my droplet. I think of my rpi as being "out in the field" and my droplet as a never-blinking observer, and an appropriate place to build what I need to house emails. Since there is so much involved in setting up the server, the folks at digital ocean try to pour water on it with why-you-may-not-want-to-run-your-own-mail-server. This article also neatly states what a person needs to do, including the (sometimes confusing) acronyms. So far, I've successfully created the LAMP stack following install-linux-apache-mysql-php-lamp-stack-on-ubuntu. What's more, I created an MX record to point to mail.(domain name) and am trying to get my ducks in a row to install postfix, where my install had been hanging. I've learned over the years not to present a question to the monastery without doing an internet search on it, so I did: just-f***ing-google.it and found installing-postfix-hangs-at-postfix-configuration-screen. I was shocked to find that the culprit was the size of my terminal. I was unable to select anything when it was small, but maximized, the install moves forward without complaint.

None of this yet touches on *receiving* email to your raspberry Pi, like giving the raspberry Pi its own DNS name with MX (mail exchange) records. That also involves Postfix (a very different configuration) and some way to locally store the email, like Dovecot IMAP.

Ok, so I just broke through with postfix and have Dovecot on the install list.

Thanks again for your comment,

In reply to Re^2: sending an email from my rpi to my droplet by Aldebaran
in thread getting SMTP capability working by Aldebaran

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.