Hello, All.

On the node, I am using the following construction:
Remap *,2:5010/278,2:5010/278.1

Since the node is a headless station, all messages to .0 need to be sent to point .1.

However, there is an issue with processing messages for AllFix ? since AllFix is essentially handled by another module (htick), it simply "doesn't see" the messages because hpt at the tossing stage already performed the remap and sent the messages to .1.

Essentially, the question is: how can we make the Remap directive not execute if the message is addressed to robots?


With best regards, Vladislav
--- Me on Telegram http://t.me/VladisMus
* Origin: (2:550/278.1)

On 16.1.2025 23.11, Vladislav Muschinskikh wrote:

On the node, I am using the following construction:
Remap *,2:5010/278,2:5010/278.1

Since the node is a headless station, all messages to .0 need to be sent
to point .1.

However, there is an issue with processing messages for AllFix ? since
AllFix is essentially handled by another module (htick), it simply
"doesn't see" the messages because hpt at the tossing stage already
performed the remap and sent the messages to .1.

Essentially, the question is: how can we make the Remap directive not
execute if the message is addressed to robots?

I'm using Carbon* to move Allfix messages to a dedicated netmail area that Allfix can read.

CarbonFromArea netmail
CarbonTo allfix
CarbonMove netmail.to.allfix

Not sure about the order of processing remap and carbon..

'Tommi

---
* Origin: nntp://rbb.fidonet.fi - Finland (2:221/360.0)

Hello, Tommi.

17 ﭢ 25 09:56, Tommi Koivula -> Vladislav Muschinskikh:

Essentially, the question is: how can we make the Remap directive
not execute if the message is addressed to robots?

I'm using Carbon* to move Allfix messages to a dedicated netmail area
that Allfix can read.

CarbonFromArea netmail
CarbonTo allfix
CarbonMove netmail.to.allfix

Not sure about the order of processing remap and carbon..

But I also don't understand this clearly, but there is a hypothesis that Carbon does not exclude Remap


With best regards, Vladislav
--- Me on Telegram http://t.me/VladisMus
* Origin: (2:550/278.1)

Hi Vladislav.

17 Jan 25 19:06:06, you wrote to me:

Essentially, the question is: how can we make the Remap directive
not execute if the message is addressed to robots?

I'm using Carbon* to move Allfix messages to a dedicated netmail
area that Allfix can read.

CarbonFromArea netmail
CarbonTo allfix
CarbonMove netmail.to.allfix

Not sure about the order of processing remap and carbon..

But I also don't understand this clearly, but there is a hypothesis
that Carbon does not exclude Remap

Should be easy to test. Just set up both, remap and carbon rules, and see what happens.

'Tommi

---
* Origin: - rbb.fidonet.fi - Finland - (2:221/360)

Hello Vladislav!

17 Jan 25, Vladislav Muschinskikh wrote to All:

AllFix is essentially handled by another module (htick), it simply "doesn't see" the messages because hpt at the tossing stage

Do you know which module command do the remapping?

hpt toss
hpt scan
hpt afix

As far as i remember "hpt toss scan" do both in one run. Importing and Exporting pkt to messagebase.

A modification does make more sense when done at the scan for export. That way it could:

import new pkt with "hpt toss"

process modificaton with "hpt afix"

export to pkt with "hpt scan".

In case that remap is done at "hpt toss" i don't see other options than to set up two configs for "hpt toss" and one of them without remap.

For testing disable your automatic mail processing, start the batchlines manually and check the result of every job.

Regards

Kai

--- GoldED+/LNX 1.1.4.7
* Origin: Monobox (2:240/77)

Hello, Kai.

18 ﭢ 25 21:25, Kai Richter -> Vladislav Muschinskikh:

AllFix is essentially handled by another module (htick), it
simply "doesn't see" the messages because hpt at the tossing
stage

Do you know which module command do the remapping?

hpt toss
hpt scan
hpt afix

Processing incoming emails occurs at the 'hpt toss' stage.
At the same time, Areafix processing is working because I have enabled the 'areafixFromPkt yes' option.

However, Remap does not interfere with the processing of emails for Areafix.

My current batch looks like this:
${BINDIR}/hpt -c $CONFIG -q toss
${BINDIR}/htick -c $CONFIG -q scan
${BINDIR}/htick -c $CONFIG -q toss

${BINDIR}/hpt -c $CONFIG -q pack

So, I don't have separate calls to 'hpt afix' and 'hpt scan'.

A modification does make more sense when done at the scan for export.
That way it could:

import new pkt with "hpt toss"

The problem lies in the fact that once the 'hpt toss' stage is completed, all mails are already processed, and htick has nothing left to do, so it effectively doesn't receive its own emails.

For testing disable your automatic mail processing, start the
batchlines manually and check the result of every job.

In my case, it's simply enough to comment out the Remap line and everything works as intended

I think maybe we could use a hook in the perl file filter() instead of Remap? And changing $toaddr to .1 if $toname does not match the regexp /fix$/i.



With best regards, Vladislav
--- Me on Telegram http://t.me/VladisMus
* Origin: (2:550/278.1)

Hello Vladislav!

19 Jan 25, Vladislav Muschinskikh wrote to Kai Richter:

Processing incoming emails occurs at the 'hpt toss' stage.

However, Remap does not interfere with the processing of emails for Areafix.

Ups, i barely noticed this. In other words: Areafix Mail to the node is not remapped to the point?

Then it would be interesting why. It sounds like hpt "knows" not to remap the Areafix mails. Then this problem was on the screen of a dev already. In that case why does it not work for known Filefix mails?

Subjectline say "AllFix" but after reviewing the docs husky does not have an "all"fix. Area control is done by hpt and File control is done by htick.

In my mind is a robot name declaration line but i can't grep it in my configs. By logic i would expect that hpt does not remap any mail that is for a robot.

So, I don't have separate calls to 'hpt afix' and 'hpt scan'.

Maybe inside some other batchfiles? Without "hpt scan" we shouldn't read your mails here. ;-)

In my case, it's simply enough to comment out the Remap line and everything works as intended

Thanks for the answer before i could ask. :)

I think maybe we could use a hook in the perl file filter() instead
of Remap?

When the first run without remap is completed then you don't have remapped mail on your point. If you run with remap again do you get your mail remapped?

If yes, then the two configs run could be a workaround.

I'm still unsure if this could be called a bug. There could be configurations that want to have a remap done before the allfix. The best soulution would be to have control on the sequence.

One last thought. The point system was designed for different physical locations. If you can do a node login and need a seperation of your personal mail from the netmail folder then "carboncopy move 'name'" could be another option.

Regards

Kai

--- GoldED+/LNX 1.1.4.7
* Origin: Monobox (2:240/77)