* Originally in nodelist-police
* Crossposted in fmail_help
Hi Wilfred.

05 Apr 26 11:29:40, Ivan Zelenyi wrote to you:

5079@inbox.ru Not directly tested, but the email address seems to
exist.

Yes, this e-mail is for receiving bundles. At March 2026, Alexey 2:5020/8912 and I tested the work of fidonode-fidopoint by e-mail. now this is relevant in the case of a total "white list".

Fmail can send mail bundles via email. It would be nice if it could search the nodelist for IMI flags. ;-)

'Tommi

---
* Origin: Point One (2:221/1.1)

* Originally in FMAIL_HELP
* Crossposted in NODELIST-POLICE

Hi Tommi,

On 2026-04-05 18:40:56, you wrote to me:

5079@inbox.ru Not directly tested, but the email address seems to
exist.

Yes, this e-mail is for receiving bundles. At March 2026, Alexey
2:5020/8912 and I tested the work of fidonode-fidopoint by e-mail. now
this is relevant in the case of a total "white list".

Fmail can send mail bundles via email. It would be nice if it could search the
nodelist for IMI flags. ;-)

It can send bundles via binkpd. It doesn't search the nodelist for IBN flags either... ?

Bye, Wilfred.

--- FMail-lnx64 2.3.2.6-B20251227
* Origin: FMail development HQ (2:280/464)

Hi Wilfred.

06 Apr 26 11:51, you wrote to me:

Fmail can send mail bundles via email. It would be nice if it
could search the nodelist for IMI flags. ;-)

It can send bundles via binkpd.

But only with help of an external binkp mailer, like binkd? Not
internally, like it can do smtp?

I don't know why this was implemented into FMail.

Ok, so you are not the guilty one. ;)

I don't think this is a job for a tosser.

I agree. There are other utilities to send bundles out from bso.

'Tommi

--- GoldED+/LNX 1.1.5-b20260304
* Origin: nntps://news.fidonet.fi (2:221/360)

Hello Tommi,

On Monday April 06 2026 20:16, you wrote to Wilfred van Velzen:

I don't know why this was implemented into FMail.

Ok, so you are not the guilty one. ;)

It was the original author, Folkert Wijstra who did it.

And it isn't a very good implementation. When packing the mail for an e-mail node, Fmail creates a standard *.pkt plus an associated *.flo. Which then is converted on the fly to an e-mail format and send out via SMTP. The *.pkt and *.flo are deleted after a succesfull transfer. But when the SMTP fails the *.pkt remains un the outbound but the *.flo is deleted. And it ends there. There is no attempt to retry after some time. Without any signaling to the sysop that the transfer has failed. Not what one would expect of a fidonet implementation.

Looks like Folkert never got arounf to properly finish it.

I don't think this is a job for a tosser.

I agree. There are other utilities to send bundles out from bso.

Indeed.


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20170303
* Origin: http://www.vlist.eu (2:280/5555)

Hi Michiel,

On 2026-04-06 14:33:50, you wrote to me:

MvdV>>> Plus that in the far future it will be even less usable because
MvdV>>> it does not support IPv6. ;-)

The very distant future. ;-)

MvdV> In 1999, I thought Fidonet would be dead by the time the real 21th century
MvdV> began. 1 jan 2001. That was a quarter of a century ago. So Fidonet might live
MvdV> for another quarter of a century and live to see the death of IPv4... ;-)

I don't think IPv4 will ever die completely, at least not in the foreseeable future.

MvdV> Speaking about extra work. In FIDOTEST a missing TZUTC kludge was
MvdV> mentioned and someone called that nitpicking. Fmail has an option to
MvdV> sort new incoming messages on date/time. I have disabled it because
MvdV> in my experience it makes thing worse most of the time.

I have it turned on, as long as I'm using FMail I suppose. I haven't noticed any downside. But fidonet messages tend to come in 1 at a time mostly, so it won't make much difference anyway.

MvdV> But... if it could sort on UTC instead of sender's local time it
MvdV> might be useful...

I'll put it on my list. I already did a similar thing in another piece of software (python script). I even made a Net to TZ table for messages that don't have a TZUTC kludge. So atleast an educated guess for the correct TZ could be made.

Bye, Wilfred.

--- FMail-lnx64 2.3.2.6-B20251227
* Origin: FMail development HQ (2:280/464)

Hi mark,

On 2026-04-06 08:12:54, you wrote to me:

I don't know why this was implemented into FMail.

because some wanted/needed to use another transmission format/protocol at times... especially when tunneling FTN through other networks and their protocols... tunneling like this is how fidonet was able to connect internationally and overseas...

It's clear why it was useful. It's not clear to me why it was implemented in a tosser, instead of in a specialized piece of separate software...

I don't think this is a job for a tosser.

creating an outbound bundle of messages in a non-FTN format? i guess i could
agree if one were FTN-centric and didn't support other non-FTN protocols...

i mean, how hard is it to output a FTN packet in UUEncode, XXEncoding, or some
other similar encoding that stores binary data in ASCII format? spit it out in
a text file into an email server's outbound or in a directory and let some other external process handle moving it to the email server's outbound...

It's not hard, just not a job for a tosser. It's a job for a mailer.

is this needed today? no but there are some who are playing around
with the old methods so they can understand things better... having a
FTN mailer that can support creating outbound FTN packets wrapped in a

^^^^^^
So you agree with me! ;-)

different form for sending via non-FTN methods isn't really bad... it
does help to alleviate the need to figure out and script the
intermediate steps...

Bye, Wilfred.

--- FMail-lnx64 2.3.2.6-B20251227
* Origin: FMail development HQ (2:280/464)

Hi Tommi,

On 2026-04-06 20:16:26, you wrote to me:

Fmail can send mail bundles via email. It would be nice if it
could search the nodelist for IMI flags. ;-)

It can send bundles via binkpd.

But only with help of an external binkp mailer, like binkd? Not
internally, like it can do smtp?

I don't know why this was implemented into FMail.

Ok, so you are not the guilty one. ;)

Nope. It was already there when I got the source code.

I don't think this is a job for a tosser.

I agree. There are other utilities to send bundles out from bso.

As it should be.


Bye, Wilfred.

--- FMail-lnx64 2.3.2.6-B20251227
* Origin: FMail development HQ (2:280/464)

Hello Wilfred,

On Monday April 06 2026 21:48, you wrote to me:

MvdV>> In 1999, I thought Fidonet would be dead by the time the real
MvdV>> 21th century began. 1 jan 2001. That was a quarter of a century
MvdV>> ago. So Fidonet might live for another quarter of a century and
MvdV>> live to see the death of IPv4... ;-)

I don't think IPv4 will ever die completely, at least not in the foreseeable future.

"Foreseeable future" is a tricky concept in these days where history may change by the day.

Strange as it may seem, it also depends on what you consider "dead". Indeed IPv4 may never die in the sense that it will be not be used at all any more. But I think we may see the day that an IPv4 only system will be less usefull and so IPv6 will becomse a must. A reversal of what we see today where an IPv6 only system is still less usefull than an IPv4 only system. After that reversal we may relatively soon get a situation where having IPv4 will have little or no added value any more and some manufacturers will stop supporting it for new products.. That may be the day when IPv45 is "dead".

It will not be relevant for Fmail. IPv4 vs IPv6 should not be relevant for a tosser and the fossile SMTP function in Fmail is the only place where it is relevant. Since that function isn't all that usefull anyway, the fact that it will not be usable at all after the death of IPv4 is academic.

MvdV>> Speaking about extra work. In FIDOTEST a missing TZUTC kludge
MvdV>> was mentioned and someone called that nitpicking. Fmail has an
MvdV>> option to sort new incoming messages on date/time. I have
MvdV>> disabled it because in my experience it makes thing worse most
MvdV>> of the time.

I have it turned on, as long as I'm using FMail I suppose. I haven't noticed any downside. But fidonet messages tend to come in 1 at a time mostly, so it won't make much difference anyway.

MvdV>> But... if it could sort on UTC instead of sender's local time
MvdV>> it might be useful...

I'll put it on my list. I already did a similar thing in another piece
of software (python script). I even made a Net to TZ table for
messages that don't have a TZUTC kludge. So atleast an educated guess
for the correct TZ could be made.

Aha. GMTA. You are ahaed of me. I was anticipating the question of "what about messages without a TZUTC kludge?" My answer would have been: "make a best guess based on Fidonet geography by node number. But you are alread there. Even to the net level. ;-)


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20170303
* Origin: http://www.vlist.eu (2:280/5555)

Hi Michiel,

On 2026-04-07 11:44:54, you wrote to me:

I don't think IPv4 will ever die completely, at least not in the
foreseeable future.

MvdV> "Foreseeable future" is a tricky concept in these days where history may
MvdV> change by the day.

MvdV> Strange as it may seem, it also depends on what you consider "dead". Indeed
MvdV> IPv4 may never die in the sense that it will be not be used at all any more.
MvdV> But I think we may see the day that an IPv4 only system will be less usefull
MvdV> and so IPv6 will becomse a must. A reversal of what we see today where an IPv6
MvdV> only system is still less usefull than an IPv4 only system. After that
MvdV> reversal we may relatively soon get a situation where having IPv4 will have
MvdV> little or no added value any more and some manufacturers will stop supporting
MvdV> it for new products.. That may be the day when IPv45 is "dead".

I'm not going to hold my breath for this to happen! ;-)

MvdV> It will not be relevant for Fmail. IPv4 vs IPv6 should not be
MvdV> relevant for a tosser and the fossile SMTP function in Fmail is the
MvdV> only place where it is relevant. Since that function isn't all that
MvdV> usefull anyway, the fact that it will not be usable at all after the
MvdV> death of IPv4 is academic.

Indeed.

MvdV>>> But... if it could sort on UTC instead of sender's local time
MvdV>>> it might be useful...

I'll put it on my list. I already did a similar thing in another piece
of software (python script). I even made a Net to TZ table for
messages that don't have a TZUTC kludge. So atleast an educated guess
for the correct TZ could be made.

MvdV> Aha. GMTA. You are ahaed of me. I was anticipating the question of "what about
MvdV> messages without a TZUTC kludge?" My answer would have been: "make a best
MvdV> guess based on Fidonet geography by node number. But you are alread there.
MvdV> Even to the net level. ;-)

Or it might be on a Region level. I don't remember exactly.

Btw: This should be an external config file, because Net structure might change more often then FMail releases...


Bye, Wilfred.

--- FMail-lnx64 2.3.2.6-B20251227
* Origin: FMail development HQ (2:280/464)

* Originally in NODELIST-POLICE
* Crossposted in FMAIL_HELP

Hi Tommi,

On 2026-04-08 12:03:39, you wrote to me:

I was looking at the code, and it turns out on both linux and windows
it uses the gethostname() function (which is posix) to get the string
to put behind the HELO command. On linux this returns the same string
as the 'uname -n' command. On windows it's the output of the 'hostname'
command. And probably just the computer name, something Michiel could
set himself if he likes to experiment with this. ;-)

So it *IS* working pretty much as it should. ;-)

You would guess so given the function name. But in practice it's not (see Michiels test)...

Bye, Wilfred.

--- FMail-lnx64 2.3.2.6-B20251227
* Origin: NPC Station (2:280/464)