1. Forum
  2. Usenet
  3. COMP.MAIL.SENDMAIL

  • [client] did not issue MAIL/EXPN/VRFY/ETRN during connection

    From HQuest@21:1/5 to All on Fri Apr 26 17:47:06 2024
    I've began to see quite a few "[client] did not issue MAIL/EXPN/VRFY/ETRN during connection" messages at my mail log files, from origins such as Mailchimp and Microsoft hosted systems. Not certain what changed, since I can still receive emails from other
    as large as places such as Google and Cisco - although a few Cisco originated emails fails with the same message, though.

    Any hints where can I begin troubleshooting this, since I don't have any visibility to the remote end, or does anyone sees anything blatantly wrong on my heavily customized cf?

    include(`../m4/cf.m4')
    VERSIONID(`2024-04-26 v1.13 for mx.domain.com: SASL - RSA certs - Hardened TLSv1.2+ PCIDSS/HIPAA/NIST - DANE- IPv6 - MTA+MSA+SMTPS - EnhDNSBL for Internet hosts - OpenARC - OpenDMARC+SPF - OpenDKIM - SpamAssassin - dovecot procmail - 4096bit FF DHParam -
    MTA-STS - SMTPUTF8 - More aggressive timeouts - SMTP smuggling fix')dnl OSTYPE(`linux')dnl
    define(`confLOG_LEVEL', `14')dnl
    define(`confOPENSSL_CNF',`')dnl
    define(`confSMTP_LOGIN_MSG',`$j $b')
    define(`confDOMAIN_NAME', `domain.com')dnl
    define(`confHELO_NAME', `mx.domain.com')dnl
    define(`confCACERT_PATH', `/etc/ssl/certs')
    define(`confCACERT', `/etc/mail/domain.com.chain.rsa.pem') define(`confSERVER_CERT', `/etc/mail/domain.com.rsa.pem') define(`confSERVER_KEY', `/etc/mail/domain.com.rsa.key') define(`confCLIENT_CERT', `/etc/mail/domain.com.rsa.pem') define(`confCLIENT_KEY', `/etc/mail/domain.com.rsa.key') define(`confDH_PARAMETERS',`/etc/ssl/certs/ffdhe4096.pem')
    dnl# Cert uses OCSP only
    dnl# define(`confCRL', `/etc/ssl/certs/revoke.crl')
    define(`confPRIVACY_FLAGS', `authwarnings,goaway,restrictqrun,restrictmailq')dnl
    define(`SMART_HOST',`mx.domain.com')
    define(`confTO_IDENT', `0')dnl
    define(`confAUTH_OPTIONS', `A p y')dnl
    define(`confAUTH_MECHANISMS', `LOGIN PLAIN')dnl
    define(`confDEF_AUTH_INFO', `/etc/mail/auth-info')dnl
    define(`confBIND_OPTS', `WorkAroundBrokenAAAA')dnl
    define(`confDANE', `always')dnl
    define(`confTO_HELO', `1m')dnl
    define(`confTO_MAIL', `30s')dnl
    define(`confTO_RCPT', `30s')dnl
    define(`confTO_DATAINIT', `45s')dnl
    define(`confTO_DATABLOCK', `5m')dnl
    define(`confTO_DATAFINAL', `1m')dnl
    define(`confTO_AUTH', `30s')dnl
    define(`confTO_STARTTLS', `1m')dnl
    define(`confTO_COMMAND', `1m')dnl
    define(`confMAX_RCPTS_PER_MESSAGE', `5')dnl
    define(`confBAD_RCPT_THROTTLE', `5')dnl
    define(`LOCAL_SRV_FEATURES',`F,o')dnl
    define(`confTLS_FALLBACK_TO_CLEAR', `False')dnl define(`confSERVER_SSL_OPTIONS',`+SSL_OP_NO_SSLv2 +SSL_OP_NO_SSLv3 +SSL_OP_CIPHER_SERVER_PREFERENCE +SSL_OP_NO_SESSION_RESUMPTION_ON_RENEGOTIATION +SSL_OP_NO_COMPRESSION')
    define(`confCLIENT_SSL_OPTIONS',`+SSL_OP_NO_SSLv2 +SSL_OP_NO_SSLv3 +SSL_OP_CIPHER_SERVER_PREFERENCE +SSL_OP_NO_SESSION_RESUMPTION_ON_RENEGOTIATION +SSL_OP_NO_COMPRESSION +SSL_OP_NO_RENEGOTIATION')
    define(`confCIPHER_LIST',`ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:
    DHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA')
    DAEMON_OPTIONS(`Family=inet6, Name=MTA-v6, Port=smtp')dnl DAEMON_OPTIONS(`Family=inet6, Name=MSA-v6, Port=submission, Modifiers=Ea')dnl DAEMON_OPTIONS(`Family=inet6, Name=MTAS-v6, Port=smtps, Modifiers=Eas')dnl EXPOSED_USER(`root')dnl
    FEATURE(`no_default_msa')dnl
    FEATURE(`use_cw_file')dnl
    FEATURE(`use_ct_file')dnl
    FEATURE(`mailertable',`hash -o /etc/mail/mailertable.db')dnl FEATURE(`virtusertable',`hash -o /etc/mail/virtusertable.db')dnl FEATURE(`access_db', `hash -T<TMPF> /etc/mail/access')dnl FEATURE(`relay_hosts_only')dnl
    FEATURE(`sts',`socket -d5 -T<TMPF> inet:8895@127.0.0.1')dnl FEATURE(`tls_session_features')dnl
    FEATURE(`masquerade_envelope')dnl
    FEATURE(`masquerade_entire_domain')dnl
    FEATURE(`local_procmail', `/usr/libexec/dovecot/dovecot-lda',`/usr/libexec/dovecot/dovecot-lda -d $u')
    FEATURE(`always_add_domain')dnl
    FEATURE(`redirect')dnl
    FEATURE(`enhdnsbl', `zen.spamhaus.org', `"554 IP address listed in Spamhaus ZEN. See https://www.spamhaus.org/query/ip/" $&{client_addr}', `127.0.0.2', `127.0.0.3', `127.0.0.4', `127.0.0.9', `127.0.0.10', `127.0.0.11')dnl
    FEATURE(`authinfo',`hash -o /etc/mail/authinfo.db')dnl INPUT_MAIL_FILTER(`opendkim', `S=inet:8894@127.0.0.1,F=T,T=R:2m') INPUT_MAIL_FILTER(`openarc', `S=inet:8893@127.0.0.1,F=T,T=R:2m') INPUT_MAIL_FILTER(`opendmarc',`S=inet:8892@127.0.0.1,F=T,T=R:2m') INPUT_MAIL_FILTER(`spamassassin', `S=local:/var/run/spamass.sock, F=, T=C:15m;S:4m;R:4m;E:10m')dnl
    define(`confMILTER_MACROS_CONNECT',`t, b, j, _, {daemon_name}, {if_name}, {if_addr}')dnl
    define(`confMILTER_MACROS_HELO',`s, {verify}, {tls_version}, {cipher}, {cipher_bits}, {cert_subject}, {cert_issuer}')dnl
    define(`confMILTER_MACROS_ENVFROM',`i, {auth_authen}, {auth_type}')dnl define(`confMILTER_MACROS_ENVRCPT',`r, v, Z, b, _')dnl LOCAL_DOMAIN(`mx.domain.com')dnl
    MAILER(local)dnl
    MAILER(smtp)dnl
    MAILER(procmail)dnl
    MODIFY_MAILER_FLAGS(`LOCAL', `-f')
    MASQUERADE_AS(`domain.com')dnl
    MASQUERADE_DOMAIN(`domain.com')dnl
    TRUST_AUTH_MECH(`LOGIN PLAIN')dnl
    LOCAL_CONFIG
    O SmtpUTF8=True
    Kcheck_client dns -R a -T T -q
    # Exclude specific hosts of networks from DNSBL checks
    HSubject: $>CheckRcptTo $: $>3 $1
    HSubject: $* OK $>3


    This is what I see when I start sendmail:
    Apr 26 13:15:28 mxhost sm-mta[128462]: starting daemon (8.18.1): SMTP+queueing@00:25:00
    Apr 26 13:15:28 mxhost sm-mta[128462]: STARTTLS: CRLFile missing
    Apr 26 13:15:28 mxhost sm-mta[128462]: STARTTLS=server, Diffie-Hellman init, key=4096 bit (/)
    Apr 26 13:15:28 mxhost sm-mta[128462]: STARTTLS=server, init=1
    Apr 26 13:15:28 mxhost sm-mta[128462]: started as: /usr/sbin/sendmail -L sm-mta -bd -q25m
    Apr 26 13:15:28 mxhost sm-msp-queue[128465]: starting daemon (8.18.1): queueing@00:25:00

    Here's a section of the logs with the debug lvl 14 enabled for a server that failed:
    Apr 26 13:16:01 mxhost sm-mta[126129]: NOQUEUE: connect from mx0a-0017d901.pphosted.com [208.84.65.218]
    Apr 26 13:16:01 mxhost sm-mta[126129]: AUTH warning: no mechanisms
    Apr 26 13:16:01 mxhost sm-mta[126129]: 43QHG1xY126129: Milter (opendkim): init success to negotiate
    Apr 26 13:16:01 mxhost sm-mta[126129]: 43QHG1xY126129: Milter (openarc): init success to negotiate
    Apr 26 13:16:01 mxhost sm-mta[126129]: 43QHG1xY126129: Milter (opendmarc): init success to negotiate
    Apr 26 13:16:01 mxhost sm-mta[126129]: 43QHG1xY126129: Milter (spamassassin): init success to negotiate
    Apr 26 13:16:01 mxhost sm-mta[126129]: 43QHG1xY126129: Milter: connect to filters
    Apr 26 13:16:01 mxhost sm-mta[126129]: 43QHG1xY126129: milter=opendkim, action=connect, continue
    Apr 26 13:16:01 mxhost sm-mta[126129]: 43QHG1xY126129: milter=openarc, action=connect, continue
    Apr 26 13:16:01 mxhost sm-mta[126129]: 43QHG1xY126129: milter=opendmarc, action=connect, continue
    Apr 26 13:16:01 mxhost sm-mta[126129]: 43QHG1xY126129: milter=spamassassin, action=connect, continue
    Apr 26 13:17:01 mxhost sm-mta[126129]: 43QHG1xY126129: timeout waiting for input from mx0a-0017d901.pphosted.com during server cmd read
    Apr 26 13:17:01 mxhost sm-mta[126129]: 43QHG1xY126129: mx0a-0017d901.pphosted.com [208.84.65.218] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA-v6

    And another section for a server that delivered:
    Apr 26 13:17:24 mxhost sm-mta[127026]: NOQUEUE: connect from mail.domain2.com [x.x.x.x]
    Apr 26 13:17:24 mxhost sm-mta[127026]: AUTH warning: no mechanisms
    Apr 26 13:17:24 mxhost sm-mta[127026]: 43QHKOr3127026: Milter (opendkim): init success to negotiate
    Apr 26 13:17:24 mxhost sm-mta[127026]: 43QHKOr3127026: Milter (openarc): init success to negotiate
    Apr 26 13:17:24 mxhost sm-mta[127026]: 43QHKOr3127026: Milter (opendmarc): init success to negotiate
    Apr 26 13:17:24 mxhost sm-mta[127026]: 43QHKOr3127026: Milter (spamassassin): init success to negotiate
    Apr 26 13:17:24 mxhost sm-mta[127026]: 43QHKOr3127026: Milter: connect to filters
    Apr 26 13:17:24 mxhost sm-mta[127026]: 43QHKOr3127026: milter=opendkim, action=connect, continue
    Apr 26 13:17:24 mxhost sm-mta[127026]: 43QHKOr3127026: milter=openarc, action=connect, accepted
    Apr 26 13:17:24 mxhost sm-mta[127026]: 43QHKOr3127026: milter=opendmarc, action=connect, accepted
    Apr 26 13:17:24 mxhost sm-mta[127026]: 43QHKOr3127026: milter=spamassassin, action=connect, accepted
    Apr 26 13:17:24 mxhost sm-mta[127026]: tls_srv_features="", relay=mail.domain2.com [x.x.x.x]
    Apr 26 13:17:24 mxhost sm-mta[127026]: STARTTLS=server, relay=mail.domain2.com [x.x.x.x], version=TLSv1.3, verify=NO, cipher=TLS_AES_256_GCM_SHA384, bits=256/256
    Apr 26 13:17:24 mxhost sm-mta[127026]: STARTTLS=server, cert-subject=, cert-issuer=, verifymsg=ok
    Apr 26 13:17:24 mxhost sm-mta[127026]: AUTH: available mech=LOGIN PLAIN, allowed mech=LOGIN PLAIN
    Apr 26 13:17:24 mxhost sm-mta[127026]: 43QHKOr4127026: milter=opendkim, action=mail, continue
    Apr 26 13:17:24 mxhost sm-mta[127026]: 43QHKOr4127026: milter=opendkim, action=rcpt, continue
    Apr 26 13:17:24 mxhost sm-mta[127026]: 43QHKOr4127026: from=<destination@domain.com>, size=334, class=0, nrcpts=1, msgid=<bb87fef9-1919-4509-89c5-202782208823@domain.com>, proto=ESMTPS, daemon=MTA-v6, relay=mail.domain2.com [x.x.x.x]
    Apr 26 13:17:24 mxhost sm-mta[127026]: 43QHKOr4127026: milter=opendkim, action=header, continue
    Apr 26 13:17:24 mxhost last message buffered 4 times
    Apr 26 13:17:24 mxhost sm-mta[127026]: 43QHKOr4127026: milter=opendkim, action=eoh, accepted
    Apr 26 13:17:24 mxhost sm-mta[127026]: 43QHKOr4127026: Milter accept: message Apr 26 13:17:24 mxhost dovecot: lda(destination)<127032><izUNH1jiK2Y48AEAsEWjtw>: msgid=<bb87fef9-1919-4509-89c5-202782208823@domain.com>: saved mail to INBOX
    Apr 26 13:17:24 mxhost sm-mta[127031]: 43QHKOr4127026: to=<destination@domain.com>, ctladdr=<destination@domain.com> (uid/gid), delay=00:00:00, xdelay=00:00:00, mailer=local, pri=30607, dsn=2.0.0, stat=Sent
    Apr 26 13:17:24 mxhost sm-mta[127031]: 43QHKOr4127026: done; delay=00:00:00, ntries=1

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Claus =?iso-8859-1?Q?A=DFmann?= @21:1/5 to HQuest on Fri Apr 26 16:23:17 2024
    HQuest wrote:
    I've began to see quite a few "[client] did not issue
    MAIL/EXPN/VRFY/ETRN during connection" messages at my mail log files,
    from origins such as Mailchimp and Microsoft hosted systems. Not certain

    Do you get any mail from them or does this always happen?

    define(`confTO_COMMAND', `1m')dnl

    Why did you choose this?

    Kcheck_client dns -R a -T T -q

    Where/how is this used?

    Apr 26 13:16:01 mxhost sm-mta[126129]: NOQUEUE: connect from mx0a-0017d901.pphosted.com [208.84.65.218]

    Apr 26 13:17:01 mxhost sm-mta[126129]: 43QHG1xY126129: timeout waiting
    for input from mx0a-0017d901.pphosted.com during server cmd read

    Maybe 1m is too short, esp. if DNS lookups take a while.
    The default is much longer - see the docs.

    --
    Note: please read the netiquette before posting. I will almost never
    reply to top-postings which include a full copy of the previous
    article(s) at the end because it's annoying, shows that the poster
    is too lazy to trim his article, and it's wasting the time of all readers.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From HQuest@21:1/5 to All on Fri Apr 26 21:19:20 2024
    Claus Aßmann wrote:
    Do you get any mail from them or does this always happen?
    From Proofpoint I used to get, but they began consistently failing in the past 2-3 weeks. From Cisco, it is a hit or miss. From a few other providers, we only recently started doing business with them, so never found in my log archives (went back to
    about 2y of past logs to confirm).

    define(`confTO_COMMAND', `1m')dnl
    Why did you choose this?
    I believe this was recommendation from a 3rd party.

    Kcheck_client dns -R a -T T -q
    Where/how is this used?
    It came as part of DNSBL setup, but judging by your reaction, seems not required, and I'm more than happy to clear it out. Less is more (except timeout, it seems).

    Apr 26 13:16:01 mxhost sm-mta[126129]: NOQUEUE: connect from
    mx0a-0017d901.pphosted.com [208.84.65.218]

    Apr 26 13:17:01 mxhost sm-mta[126129]: 43QHG1xY126129: timeout waiting
    for input from mx0a-0017d901.pphosted.com during server cmd read

    Maybe 1m is too short, esp. if DNS lookups take a while.
    The default is much longer - see the docs.
    It is interesting that these timeout changes occurred over a year ago. I can see a DNS query and response for these incoming systems happening in under 2 seconds. Will change those back to their default and see how it behaves. More to come.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From HQuest@21:1/5 to All on Sat Apr 27 01:01:20 2024
    After removing all the timeout settings and the "Kcheck_client dns" option, nothing changed - except it now fails after 5 minutes instead of 1 minute with the exact symptoms.

    I found some directions at Proofpoint site about disabling Cisco's SMTP fixup options, and confirmed no such options are configured/available on these devices sitting in front of the MX servers. There is no decryption/deep packet inspection happening for
    these connections. The IPS/IDS systems are not dropping any packets of the sessions.

    And confirmed all name resolution is performed in under 2 seconds - during the monitored sessions, successfully resolved immediately before the new connection entry was recorded by the mail log file.

    On a positive note, I got information from the remote end:

    Remote server returned "554 5.4.0 < #4.4.2>"

    Unless I'm reading this wrong, 5.4.0 seems to be on the remote/sender side, so not much I can do on my end.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From HQuest@21:1/5 to All on Sat Apr 27 00:46:14 2024
    By removing all the timeout settings and the unknown

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Claus =?iso-8859-1?Q?A=DFmann?= @21:1/5 to HQuest on Sat Apr 27 05:05:26 2024
    HQuest wrote:

    On a positive note, I got information from the remote end:

    The site which tries to connect to your sendmail server?

    Remote server returned "554 5.4.0 < #4.4.2>"

    "Remote server" would be you MTA -- but that doesn't look like
    anything sendmail would return -- unless you have "weird" entries
    in the access map.

    --
    Note: please read the netiquette before posting. I will almost never
    reply to top-postings which include a full copy of the previous
    article(s) at the end because it's annoying, shows that the poster
    is too lazy to trim his article, and it's wasting the time of all readers.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From HQuest@21:1/5 to All on Sat Apr 27 17:23:40 2024
    Claus Aßmann wrote:
    On a positive note, I got information from the remote end:
    The site which tries to connect to your sendmail server?
    Correct.

    Remote server returned "554 5.4.0 < #4.4.2>"
    "Remote server" would be you MTA -- but that doesn't look like
    anything sendmail would return -- unless you have "weird" entries
    in the access map.

    Zero entries related to these destinations. Mostly entries to allow relaying from internal networks, and options to disable, such as below. Internal entries and exceptions removed - but once again, none for any of the problematic sender domains.

    # more /etc/mail/access
    # Internal hosts whitelisted off DNS BL checks
    Connect:127.0.0.1 RELAY

    # Trusted subnets and domains
    127.0.0.1 RELAY
    domain.com RELAY

    # Exceptions for broken systems

    # Refer to section "Allowing Connections" on Sendmail's cf/README file
    #
    # Srv_features:
    # RFCs require CR LF . CR LF for end of email message. Many systems won't respect that. Set
    # G to allow for end of email with single LF
    # U to allow for end of email with single CR
    # tls_server: called when sendmail act as client, ready to send an email
    # message after a STARTTLS command (should) have been issued;
    # tls_client: called when sendmail act as server, ready to receive an email
    # message after a STARTTLS command (should) have been issued, and/or from
    # check_mail;

    # Default TLS settings
    Try_TLS: YES,VERIFY,ENCR
    TLS_Srv: VERIFY,ENCR
    TLS_Clt: VERIFY,ENCR

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Claus =?iso-8859-1?Q?A=DFmann?= @21:1/5 to HQuest on Sat Apr 27 15:47:05 2024
    HQuest wrote:

    Remote server returned "554 5.4.0 < #4.4.2>"

    Maybe you should try to connect from some "remote server"s
    to yours and see what happens?
    That is, can you reproduce this weird reply?
    If so, then it's not sendmail that's replying...

    If you can't reproduce this, maybe you should post the name/IP
    of your MTA so others could help?

    Try_TLS: YES,VERIFY,ENCR
    TLS_Srv: VERIFY,ENCR
    TLS_Clt: VERIFY,ENCR

    How did you come up with these entries? That is, which part
    of the documentation says these entries are correct?

    --
    Note: please read the netiquette before posting. I will almost never
    reply to top-postings which include a full copy of the previous
    article(s) at the end because it's annoying, shows that the poster
    is too lazy to trim his article, and it's wasting the time of all readers.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From HQuest@21:1/5 to All on Sun Apr 28 15:19:03 2024
    Claus Aßmann wrote:
    Maybe you should try to connect from some "remote server"s
    to yours and see what happens?
    That is, can you reproduce this weird reply?
    If so, then it's not sendmail that's replying...

    I cannot, unfortunately, use Proofpoint servers. I have to trust what they are notifying the sender as what's going on - and the above was the only note aside of the original message/headers, that tells me something, albeit in a very cryptic way.

    If you can't reproduce this, maybe you should post the name/IP
    of your MTA so others could help?

    No problems in sharing, but it is puzzling I get over 100k emails/day from all kinds of providers but not from a handful of large enterprise names. I was leaning towards not being a problem on my end, as your responses makes me feel like, but wanted to
    try harder before I approach these folks and ask them to work with PP. About Cisco, that's a different animal altogether and I have no idea yet.

    Try_TLS: YES,VERIFY,ENCR
    TLS_Srv: VERIFY,ENCR
    TLS_Clt: VERIFY,ENCR
    How did you come up with these entries? That is, which part
    of the documentation says these entries are correct?

    Those I have to look on our archives why and when were added (been there since first versions I could find, dated from 2016). But again, judging by your question, I'm almost positive those are not correct.

    I appreciate your time and directions. All things considered, if after all your highlighted points are removed things still look bad, I shan't blame my infra - for now.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marco Moock@21:1/5 to All on Sun Apr 28 21:13:48 2024
    On 28.04.2024 um 15:19 Uhr HQuest wrote:

    I cannot, unfortunately, use Proofpoint servers. I have to trust what
    they are notifying the sender as what's going on - and the above was
    the only note aside of the original message/headers, that tells me
    something, albeit in a very cryptic way.

    By default, sendmail logs the reported status code and DSN.
    E.g. reject=550 5.7.1 Rejected:
    Maybe grep your logs for the error code they told you.

    --
    kind regards
    Marco

    Send spam to 1714310343muell@cartoonies.org

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Claus =?iso-8859-1?Q?A=DFmann?= @21:1/5 to HQuest on Sun Apr 28 15:40:24 2024
    HQuest wrote:

    I found some directions at Proofpoint site about disabling Cisco's SMTP
    fixup options, and confirmed no such options are configured/available on

    So there is some "screwup device" in front of sendmail?
    It's broken, get rid of it.

    220 ***************************************************

    That's an obvious violation of the RFC:

    Greeting = ( "220 " (Domain / address-literal)

    --
    Note: please read the netiquette before posting. I will almost never
    reply to top-postings which include a full copy of the previous
    article(s) at the end because it's annoying, shows that the poster
    is too lazy to trim his article, and it's wasting the time of all readers.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to All on Sun Apr 28 17:00:11 2024
    On 4/28/24 14:40, Claus Aßmann wrote:
    So there is some "screwup device" in front of sendmail?
    It's broken, get rid of it.

    I'm not sure that's broken.

    I absolutely agree that it's undesired.

    Take a look at the 6th paragraph of RFC 5321 section 4.2. It's the 3rd paragraph before the ABNF that I think you're quoting:

    An SMTP client MUST determine its actions only by the reply code, not
    by the text (except for the "change of address" 251 and 551 and, if
    necessary, 220, 221, and 421 replies); in the general case, any text,
    including no text at all (although senders SHOULD NOT send bare
    codes), MUST be acceptable. The space (blank) following the reply
    code is considered part of the text. Whenever possible, a receiver-
    SMTP SHOULD test the first digit (severity indication) of the reply
    code.

    Specifically:

    - An SMTP client MUST determine its actions only by the reply code
    - not by the text
    - in the general case, any text, including no text at all ... MUST be acceptable.

    So I feel like "***************************************************" is
    not an address-literal, but it is definitely "any text". And the actual
    value of the text doesn't matter for a greeting.

    IMHO the only thing that actually matters is the "2", "2", "0", and " ".

    As much as I dislike SMTP $&#*up I don't think that it is actually a
    problem. I've seen email flow through such $&#*up many times before.

    I don't have the time much less mental fortitude to chase the ABNF that
    encodes this. But if this was the last line of a multi-line reply, I
    believe '"220" [ SP textstring ] CRLF' ABNF accounts for this.



    --
    Grant. . . .

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From HQuest@21:1/5 to Marco Moock on Sun Apr 28 21:41:10 2024
    Marco Moock wrote:
    By default, sendmail logs the reported status code and DSN.
    E.g. reject=550 5.7.1 Rejected:
    Maybe grep your logs for the error code they told you.
    Absolutely nothing on my logs that remotely resembles the message they gave me (via another email provider):

    "From MAILER-DAEMON@mx0a-0017d901.pphosted.com
    Delivery is delayed to these recipients or groups:
    user@domain.com
    Subject: xxx
    This message hasn't been delivered yet. Delivery will continue to be attempted. Diagnostic information for administrators:
    Generating server: mx0a-0017d901.pphosted.com
    user@domain.com
    Remote server returned '554 5.4.0 < #4.4.2>'

    Original message headers:"
    , followed by message headers starting at the machine attempting to contact my MX servers.

    On my mail logs, all I have are entries as of this topic's subject: "[client] did not issue MAIL/EXPN/VRFY/ETRN during connection".

    Claus Aßmann wrote:
    So there is some "screwup device" in front of sendmail?
    It's broken, get rid of it.
    220 ***************************************************
    That's an obvious violation of the RFC:
    Greeting = ( "220 " (Domain / address-literal)

    Odd - the obfuscation ("Mask server banner") is shown as disabled, but still being enforced. Can confirm via a packet capture from the external border router. I do not see any current bug that correlates to this, however I see other bugs that may cause
    drop of ESMTP connections within certain circumstances. Will review those with our security folks and possibly file a bug report, depending on the version of the security appliance, if a newer code version than the one running is not available.

    So it may be my infra, after all... much appreciated for the insight again, Claus.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to Grant Taylor on Sun Apr 28 17:03:44 2024
    On 4/28/24 17:00, Grant Taylor wrote:
    Take a look at the 6th paragraph of RFC 5321 section 4.2.  It's the 3rd paragraph before the ABNF that I think you're quoting:

    %s/3rd paragraph before the ABNF/3rd paragraph *AFTER* the ABNF/



    --
    Grant. . . .

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From HQuest@21:1/5 to HQuest on Mon Apr 29 15:40:12 2024
    HQuest wrote:
    So there is some "screwup device" in front of sendmail?
    It's broken, get rid of it.
    220 ***************************************************
    That's an obvious violation of the RFC:
    Greeting = ( "220 " (Domain / address-literal)
    Odd - the obfuscation ("Mask server banner") is shown as disabled, but still being enforced. Can confirm via a packet capture from the external border router.

    Seems everywhere I look I find new security appliances. We identified the one with the obfuscation feature enabled and managed to get approval for disabling it. I still don't receive emails from Proofpoint, but this have fixed delivery issues with
    another provider (Mailchimp). Acceptable or not (as per a separate brief discussion), this is now up to our IS group to decide if a working solution outweigh their paranoia.

    I'll continue to dig into this, now with some technical help from other manufacturers. The last bug search has raised many concerns.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)