Any capability to send mail locally?

[context]

I rarely see this discussed, but it has always seemed to be a rather straightforward and common need. Just to clarify, what I would like to do is have an account in FossaMail that checks for mail from another PC on my home network, without going to the Internet. It might be dubbed a "private email channel". Not only would it offload 'net traffic from my ISP, it would inherently have a large degree of privacy. My other accounts would need to operate normally.

Here's a short article from 2006, I believe: http://ask-leo.com/how_do_i_send_email_to_another_machine_on_my_local_network_without_hitting_the_internet.html

I'll also mention that I'm aware of the instant messaging applications. They might serve some instances, but what I need is an "in-house destination" that operates seamlessly with the other FossaMail features.

Thanks in advance for an suggestions.

[Lucio Chiappetti]

checks for mail from another PC on my home network, without going to the Internet

You do not specify your operating system environment. Surely all what you describe can be done in a Linux environment (e.g. good old sendmail to send, and imap on other PC to check it)

[context]

Very good point. My PCs are Window 7 and Windows 10.

[Moonchild]

Any mail transfer agent (MTA) installed on Windows should be able to help you out if you want to use a mail client like that without using an internet service.
Of course, this still won't be "ad-hoc" networked mail because that's simply not how SMTP works. There are, however, other available SOHO/SMB messaging systems out there that could provide alternatives.
As a client, FossaMail doesn't particularly care if your SMTP/POP/IMAP addresses are on your LAN or on the internet, so the limiting factor isn't the client here

[context]

Any mail transfer agent (MTA) installed on Windows should be able to help you out

Thanks for your reply. What you outlined sounds encouraging. But a 50-site-visit survey of topics and technology didn't connect enough dots—or provide a meaningful example—to let me actually get anywhere with the idea. Indeed, about 95% of the "knowledge" concerns setting up local email capabilities on unix/linux (as Lucio indicated). http://www.revolvy.com/main/index.php?s=Mail%20transfer%20agent&item_type=topic&sr=50 is an example of the extent of information on MTAs.

But there remains one determining question: I now have four email accounts defined in FossaMail ... all working through my ISP accounts. Is it even feasible to add a 5th that would use a local MTA to communicate with my other intranet PCs? If not, then I'll just sideline this idea.

[Moonchild]

It's certainly feasible. I have 10 accounts defined in FossaMail and could add many more if I wanted to
The question is simply: do you really need this added complexity? Won't using a regular e-mail address provided by a third party give you what you need?

As an aside I don't recommend ISP-supplied e-mail addresses. Nothing is as annoying as having to switch ISP for any reason and then no longer having access to your e-mail address as a result (with the necessary issues as a result if registrations are bound to e-mail as they regularly are these days -- with recovery of accounts also done by registered e-mail...)

As for a specific windows-based solution: I've had good experiences with MDaemon, although I don't think they still offer a free version for SOHO use which they did in the past. You may have some trouble finding free mail servers on Windows, although there do seem to be at least a few around.

[context]

Won't using a regular e-mail address provided by a third party give you what you need?

Your question points right toward the core issue: With all the revelations surrounding the monitoring and parsing of email content, I thought there might be a way to bypass the third parties ... keep them out of the loop ... for messages going to someone in my household.

Yet the convenience and versatility of email makes it hard to justify setting up LAN messaging as a separate set of processes just to cover those instances.

What I'm seeking is the best of both worlds. (And, yes, I'm aware of message encryption methods, but have avoided the additional complexity.) I had never investigated this, but figured it might be a common need that had common solutions. Now, looking at the bigger picture, it occurs to me that if FossaMail could somehow provide support, it could give a big boost to the whole concept of a local email client ... and to FossaMail, of course.

In any event, thanks for your responses.

[Lucio Chiappetti]

But there remains one determining question: I now have four email accounts defined in FossaMail ... all working through my ISP accounts. Is it even feasible to add a 5th that would use a local MTA to communicate with my other intranet PCs? If not, then I'll just sideline this idea.

Hmm ... I am not sure to understand. It should not have anything to do with the sending account but with the destination address (at least that's the way it works in Unix and with sendmail). Still, I do not understand the ... context ... I mean, I can understand you do not want to go through an ISP to send a mail between two PCs at your home ... but why would you need e-mail and not other form of file transfer ... or just voice talk. Unless it is not a home but a larger enterprise or institute.

We are for instance an institute with about one hundred PCs. These are divided in two main categories (plus "the servers"). The standalone ones (including all Windows and some of the Linux, typically the portable ones) are client of one of the (local) imap servers. Incoming mail is received on the imap server, and mail is sent via one of the SMTP servers. They use an IMAP client or a web mailer. The other ones (most of the Linux) do receive mail locally. Mail sent to the world is dispatched via one of the SMTP servers (which are in house, no ISP involved), but mail sent to local addresses (those within our domain) are sent directly bypassing the SMTP servers. In the sendmail configuration there are two "mailers", the mail directed to a local address on machine B uses the "local" mailer and travels directly from A to B; the mail to any other address e.g. machine C goes from A to X (one of the redundant SMTP servers) and from X to C. If no local mailer were defined, the path will be A to X to B.
This allows A and B to communicate even if X is down or overloaded (it might occur, rarely).

[context]

but why would you need e-mail and not other form of file transfer

The short answer is: uniform operation and simplicity for the user.

The longer answer is that having one program for all mail-type communication is better than trying to implement and operate two different ones. (With file sharing handling non-mail instances, of course.)
FossaMail, for example, lets you:
• Control the style of the text
• Embed images
• Embed links
• Attach files
Plus, messages are displayed in the same window layout (sender, subject, date, etc.), with the same lookup features and a clear chronological record of all communications. And with all of a person’s communications in one program, they have direct access to their contact list and features like forwarding.

Certainly, I was looking at this only as a home user. But it’s easy to see how this could have benefits for a small business, where all PCs are on the same intranet ... especially when communicating sensitive information, but also to simplify training and everyday use.

Thanks for adding your points.

[Moonchild]

Installing a Windows-based mail server on a LAN machine is really not that difficult and you can bypass third parties that way, and have a uniform method of communication.
Local mail servers are used for internal communication (especially sensitive content) in just about all medium and larger businesses (and some small businesses too).

There is another solution to your worry about third parties seeing e-mail content if setting up a local mail server is too complicated for you: install Enigmail (an extension to Thunderbird/FossaMail) and use encrypted e-mail. You can use any third party mail service, even the ones you know for a fact scan your e-mail, with the full peace of mind that nobody but you and your recipient can read it. v1.7.2 is what I use myself for all my encrypted mail needs.
Download: http://www.enigmail.net/index.php/en/do ... d-versions -> Choose "Thunderbird 24" and follow the instructions.

[Thehandyman1957]

Off-topic:

There is another solution to your worry about third parties seeing e-mail content if setting up a local mail server is too complicated for you: install Enigmail

Forgive me if this is considered "hijacking" this thread but I just had one quick question about this that I could not find on their site.
And it would probably help context also.

So since you said you use it, I thought I would ask. When sending an email with this add on does the recipient when replying continue
the encryption? Another words, you send an encrypted email to a friend and he replies without this add on or any encryption.
Does it continue to stay encrypted or does the reply become open?

[context]

Installing a Windows-based mail server on a LAN machine is really not that difficult and you can bypass third parties that way

Thanks for the encouragement. I've downloaded a couple of small server programs (PostOffice121 and JavaEmailServer161) to try, and will report my results (if any!) hMailServer565 is another that was listed, but appears more capable and more complicated. At this point, I'm very much proceeding in technical darkness and would certainly appreciate hearing from anyone who has used any of these with FossaMail.

[Moonchild]

Off-topic:

So since you said you use it, I thought I would ask. When sending an email with this add on does the recipient when replying continue
the encryption? Another words, you send an encrypted email to a friend and he replies without this add on or any encryption.
Does it continue to stay encrypted or does the reply become open?

The recipient can't read encrypted mail without having encryption capabilities themselves. You need the recipient's public key to be able to send encrypted mail to them.
Enigmail by default will reply encrypted when encrypted mail seems possible (the recipient's public key is known in the key manager) so yes, encryption will be continued if possible. This is, however, configurable, of course, and it takes one click in the compose window to change it per-mail.

[Thehandyman1957]

Off-topic:
The recipient can't read encrypted mail without having encryption capabilities themselves. You need the recipient's public key to be able to send encrypted mail to them.
Enigmail by default will reply encrypted when encrypted mail seems possible (the recipient's public key is known in the key manager) so yes, encryption will be continued if possible. This is, however, configurable, of course, and it takes one click in the compose window to change it per-mail.

Thank you for that information.