Mail flow issues

From GWAVA4

Jump to: navigation, search

To successfully diagnose mail flow issues, it's important to have read Servers,Interfaces, Engines, & Scanners - Basic_Objects and GWAVA 4 Components, to understand the basic parts of a GWAVA system.


Contents

General Troubleshooting

  • Are all the components, both of the messaging system and GWAVA loaded? For example a GWAVA server usually has GWAVA, GWAVAMAN, GWAVAQMS, GWAVAPOA, and GWVRELAY running at all times.
  • Look at the log files, stored in /opt/beginfinite/gwava/services/logs. Consider changing the logging level, which is under the server object, under Configure Server.
  • Can the issue be replicated? Is it limited to one set of circumstance? A particular message or message content? A specific source or destination?
  • Is the issue sporadic or constant?
  • Could the issue be a hardware problem? Disk drives, memory, CPU?
  • Is it worth taking a packet trace?
  • Is the issue machine or OS specific? Did the issue always exist, or only occur after upgrading GWAVA, GroupWise, or the OS?
  • Check the GWAVA knowledgebase or forums to see if the issue has already been reported and/or solved.
  • If the same message is processed via another interface or engine, does the same issue exist?

Troubleshooting specific interfaces

Typically you start by troubleshooting at the interface level if the actual mail flow is being interrupted or malfunctioning.

MTA

The MTA interface is loaded in an unusual fashion compared to most interfaces - the software interface "piggybacks" with the loading, unloading, and restarting of the MTA. The sequence runs something roughly like this:

  • The GroupWise MTA (GWMTA) loads.
  • During startup, it finds the existence of /vscan and other switches in its startup file.
  • This triggers a load of GWMTAVS, the Novell supplied API for virus scanning.
  • GWMTAVS in turn loads the GWAVA MTA interface -- either VS.NLM (NetWare) or libgwvsmod.so (Linux). If this fails, the mail flow may be interrupted indefinitely.
  • The GWAVA MTA interface uses its bootstrap configuration file GWAVAMTA.XML (created during installation of the MTA scanner) to contact GWAVAMAN and provide the Object ID of the interface. In absence of an overriding command in GWAVAMTA.XML, the GWAVA MTA will always try to contact its local IP interface on port 49282.
  • The GWAVA MTA interface then can obtain some configuration information from GWAVAMAN. The two most important pieces of information are the engines (configurations) attached to this interface, and what GWAVA scanner to contact (usually again this is local).
  • As each message goes through the MTA, the message is handed off to GWMTAVS and then to the GWAVA MTA interface. The messages are queued under <domain>/mslocal/gwvscan during processing.
  • The GWAVA MTA interface contacts the GWAVA scanning engine, which scans the message according to the engine configuration, and reports back the results.
  • If the message needs to be altered, the MTA interface requests that the GWAVA scanning engine does this using GWVRELAY (basically relaying an altered copy).
  • If notifications need to be generated, the GWAVA scanning engine does this using GWVRELAY.
  • The GWAVA MTA interface tells the GWMTA to either PASS (unaltered) or BLOCK (entirely) the message.


POA

The GWAVAPOA job manager is always loaded, and you'll see in the log files the IMAP connection.

  • Is the job taking place at the correct time? If not, check the schedule. Make sure the job is enabled.
  • Is IMAP enabled in the POA Agent settings, and is the hostname/ipaddress and port specified correct?
  • A common issue is running IMAP at both the POA and GWIA on the same IP address and port. This leads to a conflict where IMAP will only function for one of the GroupWise agents (whichever one loaded and initialized first). And GWAVAPOA will NOT function correctly when connecting to the GWIA IMAP.
  • Was a trusted application key minted? (Check ConsoleOne)
  • Is the issue limited to a specific user or post office? A specific folder or message?
  • Is the POA local or remote from the GWAVAPOA interface? (For best performance, the two should always be on the same server)

GWIA

  • The GWIA interface (GWVGWIA) is loaded if and only it is listed in <productRoot>/assets/conf/services.conf and the correct interface ID is specified.
  • The Novell GWIA program needs to contain a /smtphome switch in gwia.cfg pointing to the "3rd" subdirectory of GWIA, which should exist and be a subdirectory of GWIA
Outgoing
  • A message comes from the POA through one or more MTAs and hits the GWIA.
  • The GWIA converts the message to MIME and dumps the message into the <GWIA>/send directory, where <GWIA> is normally <domain>/wpgate/gwia.
  • The GWVGWIA interface contacts the GWAVA scanning engine, which scans the message according to the engine configuration, and reports back the results.
  • If the message needs to be altered, the GWVGWIA interface does this directly.
  • If notifications need to be generated, the GWAVA scanning engine does this using GWVRELAY.
  • The GWVGWIA interface either places an unaltered or altered version of the message in <GWIA>/3rd/send or deletes the message entirely.
Incoming
  • A message comes from the Internet and hits the GWIA daemon
  • The GWIA daemon dumps the message into the <GWIA>/3rd/receive directory, where <GWIA> is normally <domain>/wpgate/gwia.
  • The GWVGWIA interface contacts the GWAVA scanning engine, which scans the message according to the engine configuration, and reports back the results.
  • If the message needs to be altered, the GWVGWIA interface does this directly.
  • If notifications need to be generated, the GWAVA scanning engine does this using GWVRELAY.
  • The GWVGWIA interface either places an unaltered or altered version of the message in <GWIA>/receive or deletes the message entirely.
Personal tools