Jump to page titleUNITED STATES
hp.com home products and services support and drivers solutions how to buy
» contact hp


more options
 
hp.com home
End of Jump to page title
HP Services Software Patches
Jump to content


» software & drivers
» ask Compaq
» reference library
» forums & communities
» support tools
» warranty information
» contact support
» parts
» give us feedback

patches by topic
» DOS
» OpenVMS
» Security
» Tru64 Unix
» Ultrix 32
» Windows
» Windows NT

associated links
» what's new
» contract access
» browse patch tree
» search patch tree
» join mailing list

connection tools
» nameserver lookup
» traceroute
» ping


Find Support Information and Customer Communities for Presario.
Content starts here
HP Services Software Patches - vaxmail06_061
 
NOTE:  An OpenVMS saveset or PCSI installation file is stored
       on the Internet in a self-expanding compressed file.
       The name of the compressed file will be kit_name-dcx_vaxexe
       for OpenVMS VAX or kit_name-dcx_axpexe for OpenVMS Alpha.
 
       Once the file is copied to your system, it can be expanded
       by typing RUN compressed_file.  The resultant file will
       be the OpenVMS saveset or PCSI installation file which
       can be used to install the ECO.
 
*OpenVMS] VAXMAIL06_061 VAX V5.5-V6.1 Mail/Process Audit ECO Summary

Copyright (c) Digital Equipment Corporation 1995.  All rights reserved.

PRODUCT:    OpenVMS VAX

COMPONENT:  VAXmail Utility
            Process Auditing

SOURCE:     Digital Equipment Corporation

ECO INFORMATION:

     ECO Kit Name:  VAXMAIL06_061
     ECO Kits Superseded by This ECO Kit:  VAXMAIL05_061
                                           VAXMAIL04_061
                                           VAXMAIL03_061
                                           VAXMAIL02_061   (CSCPAT_1171 V1.0)
                                           VAXAUDI01_061
                                           VAXMAIL01_061
                                           VAXMAIL02_060   (CSCPAT_1170 V1.0)
                                           VAXAUDI01_060
                                           VAXMAIL01_060
                                           VAXMAIL06_U2055 (CSCPAT_1123 V1.2)
                                           VAXMAIL05_U2055
                                           VAXMAIL03_U2055
                                           MAIL$03_U1055
                                           MAIL$01_U1055

     ECO Kit Approximate Size:  1990 Blocks
                    Saveset A -  126 Blocks
                    Saveset B -  450 Blocks
                    Saveset C -  666 Blocks
                    Saveset D -  684 Blocks
                 Cover Letter -   64 Blocks

     Kit Applies To:  OpenVMS VAX V5.5, V5.5-1, V5.5-2, V5.5-2H4, V5.5-2HF,
                                  V6.0, V6.1
     System/Cluster Reboot Necessary:  No

     Installation Rating:  3 - To be installed on all systems running
                               the listed versions of OpenVMS which
                               are experiencing the problems described.

     NOTE:  In order to receive the full fixes listed in this kit,
            the following remedial kits also need to be installed:

                 None.



ECO KIT SUMMARY:

An ECO kit exists for the VAXmail Utility on OpenVMS VAX V5.5-2
through V6.1 and for Process Auditing on OpenVMS VAX V6.0 through
V6.1.  This kit addresses the problems described below.  The
descriptions are broken down for the different versions of OpenVMS
VAX.  Therefore, if a problem is fixed in both OpenVMS VAX V5.5-2 and
OpenVMS VAX V6.1, it will be listed twice in the problem descriptions
below.

Problems Addressed in the VAXMAIL06_061 Kit for OpenVMS VAX V5.5,
V5.5-1, V5.5-2, V5.5-2H4, V5.5-2HF, V6.0, and V6.1:

  o  This kit is being issued to update the SECURESHRP.EXE image to
     avoid installation conflicts with the VAXLOAD01_070 kit which
     also contains the SECURESHRP.EXE image.  There are no new
     fixes in this kit.  If you have installed the VAXMAIL05_061
     kit you do not need to install this kit.


Problems Addressed in the VAXMAIL05_061 Kit for OpenVMS VAX V5.5,
V5.5-1, V5.5-2, V5.5-2H4, V5.5-2HF, V6.0, V6.1:

  o  In the MAIL user interface, if a user asks for a directory of a
     nonexistent folder, the signaled message is:

          %MAIL-E-NOTEXIST, folder !AS does not exist

     The actual message should contain the name of the nonexistent
     folder rather than !AS.

     This problem is corrected in OpenVMS VAX V6.2.


Problems Addressed in the VAXMAIL05_061 Kit for OpenVMS VAX V6.1:

  o  The SECURESHRP.EXE image is common to the VAXMAIL04_061 and
     VAXLOAD01_061 kit.  In order to eliminate a possible image
     regression problem, this kit updates the SECURESHRP.EXE image to
     the same level as the image in the VAXLOAD01_061 kit.


Problems Addressed in the VAXMAIL04_061 Kit for OpenVMS VAX V5.5, V5.5-1,
V5.5-2, V5.5-2H4, V5.5-2HF, V6.0, V6.1:

  o  System status code rather than mail status code is reported.

  o  Applications that use the MAIL$ callable mail API can exhaust
     virtual memory.  This may cause system crashes due to insufficient
     virtual memory.

  o  The $GETUAI and $SETUAI services may return RMS record locked
     errors during attempts to access the SYSUAF.  These errors
     occur if the caller uses these services with a context block
     supplied (which keeps the SYSUAF open), and encounters a
     locked record for other than the initial call.  This happens
     because the RMS structures are not correctly re-initialized
     after the initial call.


Problems Addressed in the VAXMAIL03_061 Kit for OpenVMS VAX V5.5,
V5.5-1, V5.5-2, V5.5-2H4, V5.5-2HF, V6.0, V6.1:

  o  If one process is writing messages to a mail folder and another
     process is updating message headers in the same mail folder
     (as in a mail delete operation), the process that is updating
     message headers may access violate.  This may occur while using
     either callable MAIL or 'MAIL' commands in a DCL command procedure.

  o  The following error message may occur while reading mail:

     %MAIL-E-OPENIN,
     error opening DEV:[USER.MAIL]MAIL$1234567800050098.MAI; as input
     -RMS-E-FNF, file not found

     The mail message does exist but has a filename that is one
     digit different than the filename in the error message.


Problems Addressed in the VAXMAIL03_061 Kit for OpenVMS VAX V6.1:

  o  If a mail TO: address that is a local recipient's address
     is called and it references an alternate transport image
     that is not installed, MAIL appears to hang.

     In order for this hang to occur the UNWIND has to be
     initiated once the call to LIB$FIND_IMAGE_SYMBOL fails.
     This can be done in any of the following ways:

          1)  MAIL$_NOSIGNAL must be included in the input
              item list for the call to MAIL$SEND_ADD_ADDRESS.
              This causes MAIL$HANDLER to call $UNWIND.

          2)  LIB$SIG_TO_RET (which calls $UNWIND) is either enabled
              as a condition handler in the calling program or is
              called by the calling program's condition handler.

          3)  The caller calls the $UNWIND service on its own.

  o  If mail is sent from one user to another user on the same CPU or
     on the same cluster, both the broadcasted new mail notification
     message and the FROM: line contain only the username.  The
     message does not include the user's node name.


Problems Addressed in the VAXMAIL02_061 Kit for OpenVMS VAX V6.1:

  o  VAXAUDI01_061 and VAXMAIL01_061 contain different versions
     of MAILSHRP.EXE.  If a user installs VAXAUDI01_061 and then
     installs  VAXMAIL01_061 kit, image regression will occur.
     This kit (VAXMAIL02_061) combines VAXMAIL01_061 and
     VAXAUDI01_061 with the latest version of MAILSHRP.EXE to
     prevent this regression.


Problems Addressed in the VAXAUDI01_061 Kit for OpenVMS VAX V6.1:

  o  This kit corrects a security problem involving process auditing.


Problems Addressed in the VAXMAIL01_061 Kit for OpenVMS VAX V6.1:

  o  The FROM field, and the mail notification message broadcast to a
     user's terminal, uses the DECnet phase 5 full name in the node
     specification instead of the cluster alias or simple name.

  o  If a file containing a message is sent repeatedly to a recipient
     with a logical name in the disk portion of the mail file
     directory specification (the SYSTEM account, for example, using
     SYS$SYSROOT:[SYSMGR]MAIL.MAI), the sends will eventually fail
     with the following error when the MAIL image is not restarted:

          %MAIL-E-SENDERR, error sending to user SYSTEM
          -MAIL-E-OPENOUT, error opening SYS$SYSROOT:[SYSMGR]MAIL.MAI;
                           as output
          -SYSTEM-F-IVDEVNAM, invalid device name

  o  OpenVMS VAX V6.1 MAIL does not preserve the pre-OpenVMS VAX V6.1
     avoidance of DECnet connections when sending inter-cluster MAIL.

  o  If a user enters an address in the form of IN%"FRED@BC (foreign
     protocol, mismatched quoted address), LIB-F-SYNTAXERR is signaled
     and the user is returned to DCL.  Other kinds of errors generated
     by an address in the TO: line will either return the user to the
     MAIL> prompt, or ask the user if the mail should be sent anyway.

  o  Sending mail to a user from more than 1 source within a 10
     millisecond interval returns the following errors:

          %MAIL-E-SENDERR, error sending to username USERNAME
          -MAIL-W-WRITERR, error writing DISK:[USER_DIRECTORY]MAIL.MAI;1
          -RMS-F-DUP, duplicate key detected (DUP not set)

  o  An access violation (ACCVIO) occurs within MAIL$MESSAGE_SELECT
     when a mail message is selected from a mail folder and two
     processes are simultaneously accessing that same mail folder.


Problems Addressed in the VAXMAIL02_060 Kit for OpenVMS VAX V6.0:

  o  VAXAUDI01_060 and VAXMAIL01_060 contain different versions of
     MAILSHRP.EXE.  If a user installs VAXAUDI01_060 and then
     installs VAXMAIL01_060, image regression will occur.  This kit
     combines VAXMAIL01_060 and VAXAUDI01_060 with the latest version
     of MAILSHRP.EXE to prevent this regression.


Problems Addressed in the VAXAUDI01_060 Kit for OpenVMS VAX V6.0:

  o  This kit corrects a security problem involving process auditing.


Problems Addressed in the VAXMAIL01_060 Kit for OpenVMS VAX V6.0:

  o  MAIL.EXE will honor a process enabled EXQUOTA privilege for
     the 'SEND/NOEDIT' command only if it is issued after a
     'SEND/EDIT' command.

  o  When a mail file is COMPRESSed and the COMPRESS fails, the
     MAIL_xxx_COMPRESS.TMP file will be left in the MAIL directory.
     This prevents that process from being able to successfully
     re-attempt the COMPRESS until the MAIL_xxx_COMPRESS.TMP file is
     manually unprotected and deleted.

  o  If a message is moved or filed from one MAIL folder to another
     and the user does not SELECT the new folder and READ the
     message, an attempt to EXTRACT that message will fail.  However,
     the user is not notified of this failure.

  o  After a SET MAIL_DIRECTORY [.NEW_DIR] is issued by the user, some
     MAIL commands may fail.  The failure depends on the order in which
     the MAIL commands are issued.  For example,

     - DIR/FOLDER fails on a file open error attempting to open
       MAIL.MAI in the old directory

     - READ fails on a file open error attempting to open a message
       file in the old directory

     - SHOW FILE (or SHOW ALL) reports the location of the MAIL
       file and the name of the MAIL directory incorrectly

     - COMPRESS fails trying to open a MAIL file in the old
       directory

  o  If a user does not provide either a mail file name or a default
     mail file name in the call to MAIL$MESSAGE_COPY, MAILSHR
     creates SYS$LOGIN:MAIL.MAI and copies the message there.

  o  If an error occurs during processing of a call to
     MAIL$SEND_MESSAGE, the calling program may hang.  One
     example of an error would be if an attempt is made to
     send to an address containing an invalid device name.

  o  If requested, the routines MAIL$USER_BEGIN and MAIL$USER_GET_INFO
     will return the length of an output item list entry to a
     user-supplied address.  The two routines MAIL$$USER_RET_INFO_OLD
     and MAIL$$USER_RET_INFO_NEW actually return the field length
     which may cause information in fields adjacent to the user-supplied
     address to be lost.

  o  If a file containing a message is sent repeatedly to a recipient
     with a logical name in the disk portion of the mail file
     directory specification (the SYSTEM account, for example, using
     SYS$SYSROOT:[SYSMGR]MAIL.MAI), the sends will eventually fail
     with the following error when the MAIL image is not restarted:

          %MAIL-E-SENDERR, error sending to user SYSTEM
          -MAIL-E-OPENOUT, error opening SYS$SYSROOT:[SYSMGR]MAIL.MAI;
                           as output
          -SYSTEM-F-IVDEVNAM, invalid device name

  o  If a user enters an address in the form of IN%"FRED@BC (foreign
     protocol, mismatched quoted address), LIB-F-SYNTAXERR is signaled
     and the user is returned to DCL.  Other kinds of errors generated
     by an address in the TO: line will either return the user to the
     MAIL> prompt, or ask the user if the mail should be sent anyway.

  o  Sending mail to a user from more than one source within a 10
     millisecond interval returns the following errors:

        %MAIL-E-SENDERR, error sending to username USERNAME
        -MAIL-W-WRITERR, error writing DISK:[USER_DIRECTORY]MAIL.MAI;1
        -RMS-F-DUP, duplicate key detected (DUP not set)

  o  If the node name portion of an address is a logical name,  MAIL
     displays the logical translation in the TO: and CC: lines (if
     present).

  o  An access violation (ACCVIO) occurs within MAIL$MESSAGE_SELECT
     when a mail message is selected from a mail folder and two processes
     are simultaneously accessing that same mail folder.

  o  DDIF files are not consistently characterized by MAIL.EXE.

     For example, when DECW$EXAMPLES:CLOCK.DDIF is sent, with or
     without the /FOREIGN switch, the receiver does not see any
     message indicating that the file must be treated differently from
     other MAIL messages when extracted.  When foreign files are
     "read", the following message should be displayed:

        %MAIL-E-FORMSG, you cannot read this foreign format message
        Use the EXTRACT command to copy the message to an external file

     While MAIL does send CLOCK.DDIF correctly, the absence of this
     message may lead the user to believe it is an empty file, a
     message consisting of nothing but the message header, and it
     could be mistakenly deleted.

     If the MAIL command DIR/FULL is issued, the message containing
     CLOCK.DDIF has "Foreign" listed as a message attribute.

     However, some other .DDIF files, as well as other files sent with
     the /FOREIGN switch, do cause the %MAIL-E-FORMSG message to be
     displayed.


Problems Addressed in the VAXMAIL06_U2055 Kit for OpenVMS VAX V5.5,
V5.5-1, V5.5-2, V5.5-2H4, V5.5-2HF:

  o  Sending mail to a user from more than 1 source within a 10
     millisecond interval returns the following errors:

          %MAIL-E-SENDERR, error sending to username USERNAME
          -MAIL-W-WRITERR, error writing DISK:[USER_DIRECTORY]MAIL.MAI;1
          -RMS-F-DUP, duplicate key detected (DUP not set)

  o  An Access Violation may occur within MAIL$MESSAGE_SELECT
     when two processes are accessing the same mail folder if
     a user attempts to select a message from the folder.


  o  When a local user's disk quota has been exceeded, the DEC TCP/IP
     SMTP symbiont ceases delivery of mail.


Problems Addressed in the VAXMAIL05_U2055 Kit for OpenVMS VAX V5.5,
V5.5-1, V5.5-2, V5.5-2H4, V5.5-2HF:

  o  MAIL hangs when attempting to send mail to two users on a remote
     node when one has his mail forwarded to the other.

  o  The current message number in MAIL is getting set incorrectly, or
     to nonexistent message numbers as a result of BACKUP or NEXT
     commands which result in a "No more messages" error.

  o  Access Violations may occur when attempts are made to mail
     binary files.  This may also occur when files with very large
     record sizes are sent.

  o  Copying large mail messages to a drawer/directory accessible by
     an ACL will cause a protection failure when the attempt is made
     to create the external message body file.

  o  RMS$_DUP errors occur when local messages from STREAM files
     with an odd length of 3 blocks plus 465 to 511 bytes are sent.

  o  Attempts to MAIL a DDIF or DTIF compound document result in
     a send of the base file if the unsupported /FOREIGN qualifier
     is used.  However, none of the file's inclusions are sent.

  o  Disk volume used by the MAIL_SERVER process contains a large
     number of lost (not pointed to by any directory) MAIL.TXT files.

  o  User-written applications need SYSPRV to connect to a remote
     node.

  o  A program which invokes callable mail works without extraordinary
     privileges, but that same program, when invoked with SYSPRV set
     in the process privilege mask, will fail with an insufficient
     privilege message.

  o  When TPU is the selected editor (either explicitly or by default)
     and the user attempts any MAIL command which invokes the editor
     on a terminal which is not an ANSI-compliant CRT (such as a
     hard-copy terminal), TPU exits with TPU$_NONANSICRT.  However,
     the message is discarded.  The user sees the next MAIL> prompt
     without any indication that a problem exists.

  o  When a user enters the DCL command '$ MAIL FILENAME' without
     specifying an addressee,  MAIL prompts for the addressee with
     "To:".  If the user merely hits RETURN without supplying an
     addressee, MAIL exits without comment and with success status.

  o  The description of how the logical name MAIL$EDIT is used in
     MAIL is incorrect in MAILEDIT.COM, which is the example file
     of a command procedure suitable for assigning to MAIL$EDIT.

  o  MAIL cannot handle ACL protected MAIL.MAI files.  Attempting to
     COMPRESS a MAIL file, where access to that file and parent
     directory are granted via an identifier ACE on a RESOURCE owned
     by the user, fails due to privilege violation while attempting to
     rename the new file to MAIL.MAI.

  o  If a received mail message contains lines longer than the
     terminal's width (either as part of the message header, or as
     part of the message text), the message display will scroll the
     top few lines off the screen before prompting "Press return for
     more".

  o  A user program will try to disable all error signaling by turning
     on the "NOSIGNAL" option in the call to MAILSHR after discovering
     that error messages cannot be trapped with an error handler.  If
     the user then attempts to compress a MAIL file, the compress
     operation aborts just after the .TMP file is created.

  o  User A does a SET FORWARD PSI%mumble::UserC.  User B sends mail
     to PSI%mumble::UserA.  The mail happens to be a STREAM_LF file or
     a file that is not a "normal" text file.  During the forwarding
     process, the STREAM_LF format is lost and the mail message
     becomes unreadable by User C.

  o  Selecting a folder after a SEARCH command causes the search
     string to be lost.

  o  A user-written program that calls MAILSHR's callable interface
     to compress a MAIL file cannot reliably detect whether the
     compress fails.  While MAILSHR displays error strings to the
     user's terminal, it does not signal anything of consequence to
     the user's program.  Furthermore, the routine status returned
     by MAILSHR is incorrect.

  o  User says "DELETE n-m", where the highest selected message number
     is less than "n".  This causes the deletion of all the messages
     in the currently selected folder, even though all the messages
     are outside the selected deletion range.

  o  While attempting to send mail, the sender sees a "Signal with
     no arguments" error.  This occurs when mail is sent to a "broken"
     mail file.

  o  In some instances, a system crash may occur because 'NEXT_ITEM'
     is not initialized in the appropriate code.

  o  Mail occasionally neglects to display the first line of a mail
     message; however, the line is there, and will be displayed on
     subsequent attempts to display the message.

  o  Even though explicit access is ignored by Mail, when an addressee
     specification has explicit access  (e.g., To: REMOTE"USER
     CORRECTPASSWORD"::USER2), the specified password is visible at
     all destinations.

  o  When DECW$EXAMPLES:CLOCK.DDIF is sent, with or without the
     /FOREIGN switch, the receiver does not see any message indicating
     that the file must be treated differently from other MAIL
     messages when extracted.  When foreign files are "read", the
     following message is displayed:

          %MAIL-E-FORMSG, you cannot read this foreign format message
          Use the EXTRACT command to copy the message to an external file

     While MAIL does send CLOCK.DDIF correctly, the absence of this
     "flag" may lead the user to believe it is an empty file, a
     message consisting of nothing but the message header, and it
     could be mistakenly deleted.  If the MAIL command DIR/FULL is
     issued, the message containing CLOCK.DDIF has "Foreign" listed as
     a message attribute.  Some other .DDIF files, as well as other
     files sent with the /FOREIGN  switch, do cause the %MAIL-E-FORMSG
     message to be displayed.

  o  If the node name portion of an address is a logical name,  MAIL
     displays the logical translation in the TO: and CC: lines (if
     present).

  o  Some MAIL commands fail after SET MAIL_DIRECTORY [.NEW_DIR] is
     issued by the user.  Depending on the order of MAIL commands
     issued, the following may occur:

       -  DIR/FOLDER fails on a file open error attempting to open
          MAIL.MAI in the old directory

       -  READ fails on a file open error attempting to open a
          message file in the old directory

       -  SHOW FILE (or SHOW ALL) reports the location of the MAIL
          file, and the name of the MAIL directory incorrectly

       -  COMPRESS fails trying to open a MAIL file in the old
          directory

  o  MAIL.EXE will honor a process's enabled EXQUOTA privilege for
     SEND/NOEDIT, only if the SEND/NOEDIT command is issued after a
     SEND/EDIT command.

  o  A user attempts to COMPRESS his MAIL file and the COMPRESS fails.
     The failure may occur due to valid or invalid problem.  This
     leaves a MAIL_xxx_COMPRESS.TMP file in the user's MAIL directory,
     which prevents that process from being able to successfully
     re-attempt the COMPRESS until the user manually re-sets the file
     protection and deletes the .TMP file.

  o  If a message is moved or filed from one MAIL folder to another,
     and the user attempts to EXTRACT that message without first
     SELECTing the new folder then READing the message, the file
     create fails but MAIL does not notify the user.

  o  If a user does not provide either a mail file name or a default
     mail file name in the call to MAIL$MESSAGE_COPY, MAILSHR creates
     SYS$LOGIN:MAIL.MAI, and copies the message there.

  o  Two user routines, MAIL$USER_BEGIN and MAIL$USER_GET_INFO, will
     return the length of an output item list entry to a user-supplied
     address if requested.  The two routines MAIL$$USER_RET_INFO_OLD
     and MAIL$$USER_RET_INFO_NEW actually return the length.  The MAIL
     documentation states that the return length address item in the
     output item list is "a longword containing the user-supplied
     address of a word in which the routine writes the actual length
     in bytes of the information it returned."  MAIL$$USER_RET_INFO_OLD
     and MAIL$$USER_RET_INFO_NEW are writing a longword into the
     user-supplied address of a word, overwriting any adjacent field(s).

  o  A user program hangs on a call to MAIL$SEND_MESSAGE when
     attempting to send to an address containing an invalid device.
     Hangs might also occur due to other errors signaled by the
     receiving system.

  o  If a file containing a message is sent repeatedly to a recipient
     with a logical name in the disk portion of the mail file
     directory specification (the SYSTEM  account, for example, using
     SYS$SYSROOT:[SYSMGR] MAIL.MAI), the sends will eventually fail
     with the following message when the MAIL image is not restarted:

          %MAIL-E-SENDERR, error sending to user SYSTEM
           -MAIL-E-OPENOUT, error opening SYS$SYSROOT:[SYSMGR]MAIL.MAI;
                            as output
           -SYSTEM-F-IVDEVNAM, invalid device name


Problems Addressed in the VAXMAIL03_U2055 Kit for OpenVMS VAX V5.5,
V5.5-1, V5.5-2, V5.5-2H4, V5.5-2HF:

  o  A user application using callable mail establishes a condition
     handler which unwinds the stack when Mail signals an unreachable
     node (and presumably, other errors as well).  This results in the
     associated mailboxes not being deassigned, and the application
     uses all the BYTLM quota.


Problems Addressed in the MAIL$03_U1055 Kit for OpenVMS VAX V5.5,
V5.5-1:

  o  Disk volume used by the MAIL_SERVER process contains a large
     number of lost (not pointed to by any directory) MAIL.TXT files.


Problems Addressed in the MAIL$01_U1055 Kit for OpenVMS VAX V5.5,
V5.5-1:

  o  EXTRACT/FOREIGN or EXTRACTing a foreign message results in a
     file allowing all access with its protections set to W:RWED.


INSTALLATION NOTES:

The system/cluster does not need to be rebooted after this kit is
installed.  However, MAIL should be shutdown and restarted in order
for all kit changes to take effect.
Files on this server are as follows:
»vaxmail06_061.README
»vaxmail06_061.CHKSUM
»vaxmail06_061.CVRLET_TXT
»vaxmail06_061.a-dcx_vaxexe
»vaxmail06_061.b-dcx_vaxexe
»vaxmail06_061.c-dcx_vaxexe
»vaxmail06_061.d-dcx_vaxexe
privacy statement using this site means you accept its terms