reply-to address not resolvable - deferred

[di.han...@gmail.com]

Dear All,

My environment: I have two incoming mail gateways running sendmail Version 8.15.2 located in DMZ.
These two mailing server are forwarding to an internal mail server running sendmail Version 8.15.1
This server is forwarding e-mails to the internal Exchange server.
We are running DNS bind with a RPZ ( response policy zone )
Here we are using 3 zones from spamhause.org
If a domain name is listed in one of these zones the name cannot be resolved and therefore sendmail will not accepts the e-mail.
All e-mail server are using DNS servers with the same RPZ.

So far everything is working fine. ( since years )

Now I see that some e-mails hang on the internal mail gateway.
I figured out this happens, when the mail header has an entry like this:
Reply-To: dispatchclai...@consultant.com

Domain consultant.com is listed in Spamhaus’s RPZ and therefore not resolvable.
This e-mail stays in the queue with an error “(Deferred)”

So I am wondering why is this e-mail is not hanging in the external gateways.
I looked into my *.mc files but could find any hint.

Actually I would like to configure my external gateways in a way that they are blocking e-mails with a reply-to for an unknown DNS domain.
Could someone point me to some URL’s related to this issue ?


Kind regards
Hans

[Claus Aßmann]

Hans wrote:

> Domain consultant.com is listed in Spamhaus's RPZ and therefore not resolvable.

What does "not resolvable" mean here?
Temporarily?
If so, did you check the fine documentation?


8.15.1/8.15.1 2014/12/06
...
If header rewriting fails due to a temporary map lookup failure,
queue the mail for later retry instead of sending it
without rewriting the header. Note: this is done
while the mail is being sent and hence the transaction
is aborted, which only works for SMTP/LMTP mailers
hence the handling of temporary map failures is
suppressed for other mailers. SMTP/LMTP servers may
complain about aborted transactions when this problem
occurs.
See also "DNS Lookups" in sendmail/TUNING.


If it is something else, please provide more information,
e.g., logs.


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

[di.han...@gmail.com]

Dear Claus, thanks for reply.

> What does "not resolvable" mean here? Temporarily?

No. It's permanent. If I query DNS it runs into a timeout. It is the same as if the domain does not exist.

I was reading the tuning guide and hoping it is a timing issue. But I was trying this and that. But without success.

"sendmail" is rejecting if "from" is a domain which does not exist. Is this also for Reply-To available ? Obviously sendmail looks at Reply-To but reacts differently.

Here some logs. Maybe it helps. I am not sure.

I am sending from DMZ to internal via swaks ( just to test )

# swaks --to hone...@iiasa.ac.at --from fromjump82...@ma.yer.at --server ismtpgw.iiasa.ac.at --port 18000 -4 --add-header 'Reply-To: dispatchclai...@consultant.com'
=== Trying ismtpgw.iiasa.ac.at:18000...
=== Connected to ismtpgw.iiasa.ac.at.
<- 220 ismtpgw.iiasa.ac.at ESMTP IIASA mta; Wed, 11 Oct 2017 14:37:21 +0200 (CEST)
-> EHLO jump8
<- 250-ismtpgw.iiasa.ac.at Hello dzsmtp2.iiasa.ac.at [147.125.80.146], pleased to meet you
<- 250-ENHANCEDSTATUSCODES
<- 250-PIPELINING
<- 250-EXPN
<- 250-VERB
<- 250-8BITMIME
<- 250-SIZE 50000000
<- 250-DSN
<- 250-AUTH GSSAPI DIGEST-MD5 CRAM-MD5
<- 250-DELIVERBY
<- 250 HELP
-> MAIL FROM:<fromjump82...@ma.yer.at>
<- 250 2.1.0 <fromjump82...@ma.yer.at>... Sender ok
-> RCPT TO:<hone...@iiasa.ac.at>
<- 250 2.1.5 <hone...@iiasa.ac.at>... Recipient ok
-> DATA
<- 354 Enter mail, end with "." on a line by itself
-> Date: Wed, 11 Oct 2017 14:37:21 +0200
-> To: hone...@iiasa.ac.at
-> From: fromjump82...@ma.yer.at
-> Subject: test Wed, 11 Oct 2017 14:37:21 +0200
-> Message-Id: <20171011143721.017816@jump8>
-> X-Mailer: swaks v20170101.0 jetmore.org/john/code/swaks/
-> Reply-To: dispatchclai...@consultant.com
->
-> This is a test mailing
->
-> .
<- 250 2.0.0 v9BCbL22017067 Message accepted for delivery
-> QUIT
<- 221 2.0.0 ismtpgw.iiasa.ac.at closing connection
=== Connection closed with remote host.


This is the syslog entry on the recipient site:

Oct 11 14:37:21 jump4 sendmail[17067]: [ID 801593 mail.info] v9BCbL22017067: from=<fromjump82...@ma.yer.at>, size=320, class=0, nrcpts=1, msgid=<20171011143721.017816@jump8>, proto=ESMTP, daemon=Daemon0, relay=dzsmtp2.iiasa.ac.at [147.125.80.146]
Oct 11 14:40:21 jump4 sendmail[17069]: [ID 801593 mail.crit] v9BCbL22017067: SYSERR(root): timeout writing message to smtpgw.iiasa.ac.at
Oct 11 14:40:21 jump4 sendmail[17069]: [ID 801593 mail.info] v9BCbL22017067: to=<hone...@iiasa.ac.at>, delay=00:03:00, xdelay=00:03:00, mailer=smtpiiasa, pri=120320, relay=smtpgw.iiasa.ac.at [147.125.99.199], dsn=4.0.0, stat=Deferred: Name server: smtpgw.iiasa.ac.at: host name lookup failure
Oct 11 14:45:00 jump4 sendmail[18599]: [ID 801593 mail.crit] v9BCbL22017067: SYSERR(root): timeout writing message to smtpgw.iiasa.ac.at
Oct 11 14:45:00 jump4 sendmail[18599]: [ID 801593 mail.info] v9BCbL22017067: to=<hone...@iiasa.ac.at>, delay=00:07:39, xdelay=00:03:00, mailer=smtpiiasa, pri=210320, relay=smtpgw.iiasa.ac.at [147.125.99.199], dsn=4.0.0, stat=Deferred: Name server: smtpgw.iiasa.ac.at: host name lookup failure
Oct 11 14:50:01 jump4 sendmail[20331]: [ID 801593 mail.crit] v9BCbL22017067: SYSERR(root): timeout writing message to smtpgw.iiasa.ac.at
Oct 11 14:50:01 jump4 sendmail[20331]: [ID 801593 mail.info] v9BCbL22017067: to=<hone...@iiasa.ac.at>, delay=00:12:40, xdelay=00:03:00, mailer=smtpiiasa, pri=300320, relay=smtpgw.iiasa.ac.at [147.125.99.199], dsn=4.0.0, stat=Deferred: Name server: smtpgw.iiasa.ac.at: host name lookup failure
Oct 11 15:00:01 jump4 sendmail[22497]: [ID 801593 mail.crit] v9BCbL22017067: SYSERR(root): timeout writing message to smtpgw.iiasa.ac.at
Oct 11 15:00:01 jump4 sendmail[22497]: [ID 801593 mail.info] v9BCbL22017067: to=<hone...@iiasa.ac.at>, delay=00:22:40, xdelay=00:03:01, mailer=smtpiiasa, pri=390320, relay=smtpgw.iiasa.ac.at [147.125.99.199], dsn=4.0.0, stat=Deferred: Name server: smtpgw.iiasa.ac.at: host name lookup failure

And so on. As it is still in queue hanging.

This is the content of the q-file

V8
T1507725441
K1507728212
N9
P840320
I0/3/99769
MDeferred
Fbs
$_dzsmtp2.iiasa.ac.at [147.125.80.146]
$rESMTP
$sjump8
${daemon_flags}EE
${if_addr}147.125.99.199
S<fromjump82...@ma.yer.at>
rRFC822; hone...@iiasa.ac.at
RPFD:<hone...@iiasa.ac.at>
H?P?Return-Path: <M-^Ag>
H??Received: from jump8 (dzsmtp2.iiasa.ac.at [147.125.80.146])
by ismtpgw.iiasa.ac.at with ESMTP id v9BCbL22017067
for <hone...@iiasa.ac.at>; Wed, 11 Oct 2017 14:37:21 +0200 (CEST)
H??Date: Wed, 11 Oct 2017 14:37:21 +0200
H??To: hone...@iiasa.ac.at
H??From: fromjump82...@ma.yer.at
H??Subject: test Wed, 11 Oct 2017 14:37:21 +0200
H??Message-Id: <20171011143721.017816@jump8>
H??X-Mailer: swaks v20170101.0 jetmore.org/john/code/swaks/
H??Reply-To: dispatchclai...@consultant.com
.


Kind regards
Hans

[Claus Aßmann]

> No. It's permanent. If I query DNS it runs into a timeout. It is the same as if the domain does not exist.

A "timeout" is NOT the same as "domain does not exist"
(the former is a temp.fail the latter permanent).

> I was reading the tuning guide and hoping it is a timing issue. But I was trying this and that. But without success.

"this and that" would be?

Did you miss this part of TUNING?
------------------------------------------------------------
Note: starting with 8.15, sendmail will not ignore temporary map
lookup failures during header rewriting, which means that DNS lookup
problems even for headers will cause messages to stay in the queue.
Hence it is strongly suggested to use the nocanonify feature;
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
at least turning it on for the MTA, but maybe disabling it for the
MSA, i.e., use Modifiers for DaemonPortOptions accordingly.
As a last resort, it is possible to override the host map to ignore
temporary failures, e.g.,
Khost host -t
However, this can cause inconsistent header rewriting.
------------------------------------------------------------

[Grant Taylor]

On 10/11/2017 07:34 AM, di.han...@gmail.com wrote:
> No. It's permanent. If I query DNS it runs into a timeout. It is the
> same as if the domain does not exist.

I would suggest re-configuring the RPZ to return NXDOMAIN instead of
TEMPERROR.



Grant. . . .
unix || die

[di.han...@gmail.com]

Dear All,
thanks for coming back.
In the meantime my RPZ is configured with "policy nxdomain".
Original sendmail was configured with FEATURE(`nocanonify')
I tried without this feature too. No difference.

If we receive an e-mail from a sender address which is in our RPZ it is successfully rejected. But if the e-mail has a Reply-To from a blacklisted domain it is accepted. ( See below ) For me this makes no sense. Because first of all, I see a lot of spams coming with a fake Reply-To and second the user cannot reply in any case.

Maybe I didn't look close enough to the fine documentation how to configure sendmail to reject such e-mails and you can point me to the right way.

If this isn't the case. Could this be a feature request for the next version 8.16 of sendmail not to accept e-mails from a non existing domain in the reply-to field ?


Kind regards
Hans

--

# swaks --to hone...@iiasa.ac.at --from ab...@herlyam.date --server 147.125.80.146
=== Trying 147.125.80.146:25...
=== Connected to 147.125.80.146.
<- 220 dzsmtp2.iiasa.ac.at ESMTP IIASA mta; Fri, 3 Nov 2017 11:25:21 +0100 (CET)
-> EHLO xxxxxxxxxxxxxxxx
<- 250-dzsmtp2.iiasa.ac.at Hello xxxxxxxxxxxxxxxxxxxxx, pleased to meet you
<- 250-ENHANCEDSTATUSCODES
<- 250-PIPELINING

<- 250-8BITMIME
<- 250-SIZE 50000000

<- 250-STARTTLS
<- 250 HELP
-> MAIL FROM:<ab...@herlyam.date>
<** 553 5.1.8 <ab...@herlyam.date>... Domain of sender address ab...@herlyam.date does not exist
-> QUIT
<- 221 2.0.0 dzsmtp2.iiasa.ac.at closing connection

=== Connection closed with remote host.

# swaks --to hone...@iiasa.ac.at --from some...@gmail.com --server 147.125.80.146 --add-header 'Reply-To: ab...@herlyam.date'
=== Trying 147.125.80.146:25...
=== Connected to 147.125.80.146.
<- 220 dzsmtp2.iiasa.ac.at ESMTP IIASA mta; Fri, 3 Nov 2017 11:25:47 +0100 (CET)
-> EHLO xxxxxxxxxxxxxxxxxxxx
<- 250-dzsmtp2.iiasa.ac.at Hello xxxxxxxxxxxxxxxxxxxxx, pleased to meet you
<- 250-ENHANCEDSTATUSCODES
<- 250-PIPELINING

<- 250-8BITMIME
<- 250-SIZE 50000000

<- 250-STARTTLS
<- 250 HELP
-> MAIL FROM:<some...@gmail.com>
<- 250 2.1.0 <some...@gmail.com>... Sender ok

-> RCPT TO:<hone...@iiasa.ac.at>
<- 250 2.1.5 <hone...@iiasa.ac.at>... Recipient ok
-> DATA
<- 354 Enter mail, end with "." on a line by itself

-> Date: Fri, 03 Nov 2017 11:25:47 +0100
-> To: hone...@iiasa.ac.at
-> From: some...@gmail.com
-> Subject: test Fri, 03 Nov 2017 11:25:47 +0100
-> X-Mailer: swaks v20130209.0 jetmore.org/john/code/swaks/
-> Reply-To: ab...@herlyam.date

->
-> This is a test mailing
->
-> .

<- 250 2.0.0 vA3APl88027662 Message accepted for delivery
-> QUIT
<- 221 2.0.0 dzsmtp2.iiasa.ac.at closing connection

[Claus Aßmann]

Hans wrote:

> If we receive an e-mail from a sender address which is in our RPZ it is successfully rejected. But if the e-mail
> has a Reply-To from a blacklisted domain it is accepted. ( See below ) For me this makes no sense. Because first
> of all, I see a lot of spams coming with a fake Reply-To and second the user cannot reply in any case.

sendmail offers rulesets to handle headers. Hence you can implement
that feature yourself -- take the rules for handling the envelope
sender as example.

[di.han...@gmail.com]

Dear Claus, thanks for reply.

Actually I can't implement this feature by myself. It has many reasons. First of all I don't have the knowledge to dig deep into the M4 programming language in combination with sendmail and than I don't have the time to do it as there are many other tasks I am responsible beside the mail gateways. Even it would be interesting to do more in this area.

If there is no simple way with a FEATURE() statement or so in the .mc file it will not be implemented. It's not a big issue.
Maybe I find later a ready to go ruleset.

Have a nice day,
Hans