Automatic Email processing before delivering to user

[joukj]

Hi,

Up to know I used DELIVER (http://vms.process.com/scripts/fileserv ... om?DELIVER) to do some processing (i.e. a virus check) before delivering the Email to the user.
However recently I came along some servers who send RFC-headers with longer lines than 256 characters. IIt sems that DELIVER chokes on this. I tried to change the maximum line length on all the open-statements in the PASCAL code, but without success. No idea how to proceed from here.

When searching the web I came along this documentation:
https://vmssoftware.com/docs/VSI_TCPIP_ ... D_VOL1.PDF
In chapter 4.3.1 it gives some ways to deliver a mail to a DCL-procedure. That is exactly what I need. However this documention from 2020 is for VSI TCPIP 10.6. I cannot fond this feature in the manuals of VSI TCPIP 6.0. Is this feature gone? or is there some way around?

Regards
Jouk

[m_detommaso]

VSI TCP/IP for OpenVMS Version 10.6 was based on Process Software’s MultiNet for OpenVMS code base; the project has been abandoned in September 2020.

The only IP stack currently in development for Alpha, Integrity, and x86 platforms is TCP/IP Service for OpenVMS V6.0; it is based on HPE TCP/IP Service for OpenVMS V5.7ECO5. This new release consolidates the existing ECO kits and provides many new features.

Below is the announcement released by VSI :

"The second roadmap change is a shift in the TCP/IP network stack strategy. VSI focus has been on developing VSI TCPIP, based on the Process Software Multinet code base, as a replacement for VSI TCPIP Services for OpenVMS. However, VSI has decided to change direction and is planning new releases of VSI TCPIP Services for OpenVMS for Alpha, Integrity, and x86 to allow customers to maintain their current network configuration if they choose. These new releases will consolidate existing ECO kits and will provide updated cryptography in SSH, SFTP, and SCP. VSI will provide schedule details on new VSI TCPIP Services releases as our plans solidify."

The tools included in VSI TCP/IP release 10.6, which were based on the Multinet IP stack, are not available for TCP/IP Service for OpenVMS V6.0 (which is a completely different code).

I hope this helps,
/Maurizio

[joukj]

Than I have realy to find out why DELIVER chokes on long input lines.

[arne_v]

I can only think of a few reasons:
1) open record length
2) string lengths
3) problems in VSI software and not in DELIVER

Do you have example, description and error message?

[craigberry]

What are the Pascal open statements opening? If they are files, what sort of files are they? ANALYZE/RMS/FDL might tell you something, like whether they have a fixed record length.

[lastovica@sciinc.com]

Than I have realy to find out why DELIVER chokes on long input lines.

can you describe exactly what "chokes" means? do you receive any sort of an error message or explicit indication of a problem?

[joukj]

I changed all the open statements with updated record length (=512). String length are also updated. However deliver does some tricks with FAB/RAB. I even added the fab$w_mrs before opening the FAB. This should contain a copy of the data VMS-Mail puts through to DELIVER, but is of course deleted after the program finishes while writing a copy to the home-directory of the user. This copy contains all the data up to the long line, which is the first missing line in the file.
DELIVER issues an error message that appears in returned mails(but most of the time no returned mails appear). This message reads:

%%%%%%%%%%%% 30-AUG-2024 13:57:17.89 %%%%%%%%%%%%
%MAIL-E-SENDERR, error sending to user JOUKJ at LOCAL:.HOPAK
-DELIVER-E-MESREAERR, Error reading intermediate message file, status = 98728

If you look at the code this suggests that the error occurs at a $GET(RAB) statement.

Note that if all the line lengths are not longer than 256 characters everything works fine.


Jouk

[martinv]

Jouk,

have a look at deliver.pas, line 150:

Code: Select all

  parameter_size     = 256;     (* Size of a single parameter in the
                                   MAIL.DELIVERY file. This is also the
                                   maximum size of lines read from any file. *)

That constant is used e.g. in the definition of the string type (which is used to define a "line") and in function get_line()

Code: Select all

    message_RAB.RAB$L_UBF := iaddress (line.body);
    message_RAB.RAB$W_USZ := parameter_size;

I have not yet tried to debug it, but it looks like an interesting subject.

HTH,
Martin

[joukj]

changing the "parameter_size = 256; " to "parameter_size = 512;" was the first thing I tried, but it seems not to help

[martinv]

The string type defined (as "varying [parameter_size] of char") as well as the RAB$W_USZ can take values of up to 65535. Why stop at 512? Try something like 2048

98728 clearly says %RMS-W-RTB, record too large for user's buffer