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

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.

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.

By removing all the timeout settings and the unknown

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.

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.

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

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.

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.

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

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.

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.

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. . . .

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. . . .

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.