On 10/7/20 1:17 PM, Tomas By wrote:
Well, in theory it could possibly be directly between 200LX and
Internet, without any PO, but realistically: yes.
I don't see how that would work. If all the client knows how to do is
talk to a cc:Mail Post Office, then I think the Post Office is going to
be /required/. Now, if the client knows how to talk to something other
than the P.O. ... sure.
It's been a while now, but one cc:Mail PO version I tried had an SMTP
add-on for sending mail, and also, I believe, POP/IMAP for dial-up,
i.e. acting as a server using those protocols.
I'm not surprised that such a gateway existed.
What I believe I am looking for is a POP/IMAP client side, to run
on/with the cc:Mail PO, getting mails from Internet to cc:Mail.
Agreed.
Or something to perform that function, even if it's not the original
solution from Lotus (or whomever owned cc:Mail before Lotus acquired them).
Right.
But there were bridges, apparently, so they must have done it?
Ya. I think gateways were the quintessential solution to connect P.O.s
to the Internet or other email systems in the '80s & '90s.
Sounds good.
See my other reply from a few minutes ago.
No, it can be separate.
;-)
So getting the mail from fetchmail into cc:Mail should be possible
with the Lotus dev stuff?
I don't know about the dev stuff.
I was thinking about an SMTP gateway in-to / out-of a cc:Mail P.O. Then
have fetchmail (et al.) pull email from wherever and feed it into the
SMTP gateway.
If by system you mean cc:Mail then I do not really see how this works.
No. I mean configure a new (sub)domain with it's own MX record that
point to the SMTP gateway (probably via intermediate SMTP server) so
that email naturally flows into it.
You can't (practically) have @domain-one.example email go into two
separate SMTP servers. So one trick is to feed it into one and have it
selectively forwad specific addresses to @ccmail-domain.example.
Aside: There are ways to do this, but they are complex and most people
don't want to go there. E.g. Sendmail's LDAP routing.
--
Grant. . . .
unix || die
