Email address being blocked?

[HudsonRecords]

I'm sending an email from an Itanium server to a distribution list.  I am in the list and another email address is in the list that goes to a Nagios server as a service check.  I receive the email but the Nagios server does not.  Both addresses are in the same domain.  This does work on a different Itanium server.

MAIL/SUBJECT="CUST FROM CUSTTN (CUST) SUCCESS" MAIL.BODY @MAIL2.DIS

How can I see the activity that might show why this email is not being received?  The .log file indicated by tcpip>show config smtp is empty.  The other log files in that directory don't have any data from today.

Thanks.

Steve

[Mark_Corcoran]

It's not clear from your post how big the distribution list is, but one thing I have found is that if the list is approximately 1024 characters in size, then beyond a certain address, it will be truncated (this is due to processing by the DCL CLI when it parses the "@dislistname"), so I would check first of all that your list size isn't hovering around that size (you also need to take into account carriage returns, line feeds, and potentially other stuff like length-encoding byte/word) - it may appear to work on another system because the order of addresses in the DL is different, so it's actually a different address at which the truncation occurs).

Beyond that, there are some logical names that you can define which may help with your analysis.

I spent some time a while ago extrapolating logical names from an - even then - old copy of the Compaq TCP/IP Services for OpenVMS Management V5.1 manual (AA-LU50L-TE, JAN-2001).

I won't go into detail as to what the various logical names do, and what type/value of equivalence name they need (Boolean, integer etc.) - it's left as an exercise for the the reader once you've found/downloaded a copy of the manual (or a more up-to-date copy for your version).

TCPIP$SMTP_8BITMIME_HACK
TCPIP$SMTP_ALTGATE_ALWAYS
TCPIP$SMTP_COMMON
TCPIP$SMTP_INBOUND_NOXVMS
TCPIP$SMTP_JACKET_LOCAL
TCPIP$SMTP_LOCAL_ALIAS_ONLY
TCPIP$SMTP_LOG_LEVEL
TCPIP$SMTP_LOG_LINE_NUMBERS
TCPIP$SMTP_MIME_HACK
TCPIP$SMTP_MTS_ALLIN1
TCPIP$SMTP_MX_IF_NOALTGATE
TCPIP$SMTP_NO_MX
TCPIP$SMTP_NO_SUBS_DOMAIN_INBOUND
TCPIP$SMTP_NOSEY
TCPIP$SMTP_POSTMASTER_ALIAS
TCPIP$SMTP_PROHIBIT_USER_HEADERS
TCPIP$SMTP_RECV_TRACE
TCPIP$SMTP_RECV_DEBUG
TCPIP$SMTP_RECV_SNAPSHOT_BLOCKS
TCPIP$SMTP_REWRITE_MTS_FROM
TCPIP$SMTP_SFF_REQUIRES_PRIV
TCPIP$SMTP_SYMB_SNAPSHOT_BLOCKS
TCPIP$SMTP_SYMB_TRACE
TCPIP$SMTP_VMSDEF_TO
TCPIP$SMTP_VMSMAIL_PARSE
TCPIP$SMTP_VMSMAIL_SEND

Of course, there may be more logical names that have since been added, or some of the above have become obsolete/deprecated.

This reminds me that whilst housekeeping my directory on a test system recently, I found some (IIRC) TRACE.TXT files in my own directory, which were generated by SMTP as a result of me having defined one or more of these logicals (or the UCX equivalent) whilst trying to get to the bottom of email problems I was having (truncation of email addresses as I alluded to, and callable mail routines hanging on a test system when specifying an internet-style address (the SMTP symbiont was attempting DNS translation of the "@domain" part for each address;  the test system is on a closed network with no gateway & no DNS server, and the DL was full of internet-style addresses, making the process that was calling the callable mail routines appear to be stuck)).

Hopefully one or ''tother of these suggestions will help.

If you do find the cause, please do come back and let us all know;  you never know when someone else will suffer from the same problem in future.

Mark

[Steven Schweda]

> How can I see the activity that might show why this email is not being
> received? [...]

   I don't know.  Most of the available diagnostics deal with receiving,
not sending (TCPIP$SMTP_RECV_TRACE, for example).

   I don't use "@list" mail distribution lists, so I know nothing, but I
can't see what's in yours, and the HELP says that you should 'enclose
this construction in quotation marks (").'

   What happens if you manually specify the problem address from that
list?  (Is the problem with the address or with the list?)

      tcpip show version

[Ian Miller.]

$ DEFINE/SYSTEM TCPIP$SMTP_LOG_LEVEL 3

stop and start SMTP

you should now get useful information in the SMTP log file.