* 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)

On 2026 Apr 06 11:51:38, you wrote to Tommi Koivula:

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.

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...

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...

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 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...

I'm not removing the function, but I'm also not going to extend it...

that's reasonable...

)\/(ark

"The soul of a small kitten in the body of a mighty dragon. Look on my majesty, ye mighty, and despair! Or bring me catnip. Your choice. Oooh, a shiny thing!"
... If a parsley farmer is sued, can they garnish his wages?
---
* Origin: (1:3634/12.73)

Hi Wilfred.

05 Apr 26 21:51, you wrote to me:

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.

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

'Tommi

--- FMail-lnx64 2.3.2.6-B20260403
* Origin: FPoint (2:221/6.66)

Hi Tommi,

On 2026-04-06 08:32:22, 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. I don't think this is a job for a tosser. I'm not removing the function, but I'm also not going to extend it...

Bye, Wilfred.

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

Hello Wilfred,

On Monday April 06 2026 11:51, you wrote to Tommi Koivula:

Hi Tommi,

On 2026-04-06 08:32:22, 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. I don't think this
is a job for a tosser.

Indeed. It isn't a job for a tosser, so why was it implemented in the first place? And if it was, why only half? It is outgoing only. One would expect those who use outgoing e-mail to have use for incoming as well. Folkert has left us decades ago, so I guess it is no use to try to get the answer from him.

I'm not removing the function, but I'm also not going to extend it...

I have used it in the past to send mail to a node who had temporary problems with his binkp server, but that was long ago, before my e-mail providers stopt accepting SMTP without SSL/TLS and/or user verification. And no longer port 25 but port 465 or 587.

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

Might as well drop it or only make it accesable in "retro mode". ;-)


Cheers, Michiel

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

Hi Michiel,

On 2026-04-06 13:03:00, you wrote to me:

I don't know why this was implemented into FMail. I don't think this
is a job for a tosser.

MvdV> Indeed. It isn't a job for a tosser, so why was it implemented in the first
MvdV> place? And if it was, why only half? It is outgoing only. One would expect
MvdV> those who use outgoing e-mail to have use for incoming as well. Folkert has
MvdV> left us decades ago, so I guess it is no use to try to get the answer from
MvdV> him.

The original FMail website is still up, and has his email address on it. So you can try and contact him if you like. ;-)
But I doubt he remembers the details.

I'm not removing the function, but I'm also not going to extend it...

MvdV> I have used it in the past to send mail to a node who had temporary problems
MvdV> with his binkp server, but that was long ago, before my e-mail providers stopt
MvdV> accepting SMTP without SSL/TLS and/or user verification. And no longer port 25
MvdV> but port 465 or 587.

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

The very distant future. ;-)

MvdV> Might as well drop it or only make it accesable in "retro mode". ;-)

That is extra work. I'll leave it as is... ;-)


Bye, Wilfred.

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

Hello Wilfred,

On Monday April 06 2026 14:22, you wrote to me:

MvdV>> Indeed. It isn't a job for a tosser, so why was it implemented
MvdV>> in the first place? And if it was, why only half? It is
MvdV>> outgoing only. One would expect those who use outgoing e-mail
MvdV>> to have use for incoming as well. Folkert has left us decades
MvdV>> ago, so I guess it is no use to try to get the answer from him.

The original FMail website is still up, and has his email address on
it. So you can try and contact him if you like. ;-) But I doubt he remembers the details.

I doubt it too, so I won't bother.

MvdV>> I have used it in the past to send mail to a node who had
MvdV>> temporary problems with his binkp server, but that was long
MvdV>> ago, before my e-mail providers stopt accepting SMTP without
MvdV>> SSL/TLS and/or user verification. And no longer port 25 but
MvdV>> port 465 or 587.

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

The very distant future. ;-)

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

MvdV>> Might as well drop it or only make it accesable in "retro
MvdV>> mode". ;-)

That is extra work. I'll leave it as is... ;-)

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

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


Cheers, Michiel

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

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)