I have configured an email server using sendmail-8.13.8 on Slackware
11.0 for a domain using dynamic DNS. I route external mail leaving the
server through my ISP since mail leaving the server directly often
bounces because the reverse lookup at the other end doesn't match
mydomain.com. For 99% of the time, relaying through my ISP works fine,
but for two domains that I want to deliver mail to, it doesn't appear
to work. The mail doesn't bounce, it just goes out never to be seen
again.

I suspect it is sill a reverse lookup problem. If I look at the
headers of the outbound mail, the first stop is the local sever where
it shows as "from localhost (username@localhost)by host.mydomain.com
(8.13.8/8.13.8/Submit) with ESMTP id l12345678for ...".

The second stop is also the local server where it shows as "from
host.mydomain.com (localhost [127.0.0.1])by host.mydomain.com
(8.13.8/8.13.8/Submit) with ESMTP id l12345679for ...".

The third stop is the ISP server where it shows as "from
host.mydomain.com ([my.ip.addr.ess]) by host.mail.myisp.net with ESMTP
id <20070202123456.WABC123.host.mail.myisp.net@host.m ydomain.com> for
...."

After that, there is no reference to host.mydomain.com in the header.

I suspect, and it is only a WAG, that the
"<20070202123456.WABC123.host.mail.myisp.net@host. mydomain.com>" is the
problem. I think it is the host.mydomain.com at the end that is
failing a reverse lookup check for those mail servers that look at the
originating domain as well as the domain of the mail server that the
email is arriving from.

I also suspect that I could cure this if I masquerade the envelope so
that the envelope shows a domain of myisp.net when it leaves my server.
After doing some reading it would appear that one of way of doing this
is using "FEATURE(genericstable)", but that also appears to require
that an entry has to be made for each user, including new users.

Based on this:

1. What are the chances that my analysis is correct?

2. If it is correct, is there a one time cure for the entire domain
rather than on a user by user basis?

3. If it is not correct, do you have any suggestions on what the
problem might be?

Thanks.

HSD wrote:
> I have configured an email server using sendmail-8.13.8 on Slackware
> 11.0 for a domain using dynamic DNS. I route external mail leaving the
> server through my ISP since mail leaving the server directly often
> bounces because the reverse lookup at the other end doesn't match
> mydomain.com. For 99% of the time, relaying through my ISP works fine,
> but for two domains that I want to deliver mail to, it doesn't appear
> to work. The mail doesn't bounce, it just goes out never to be seen
> again.

It's always nice to see a fellow Slack'er. That's no good on the email though. We use to be able to say that email would either arrive, or you would get bounce. However, now with all the other imitation MTAs on the market, sadly we can no longer say that.

> I suspect it is sill a reverse lookup problem. If I look at the
> headers of the outbound mail, the first stop is the local sever where
> it shows as "from localhost (username@localhost)by host.mydomain.com
> (8.13.8/8.13.8/Submit) with ESMTP id l12345678for ...".
>
> The second stop is also the local server where it shows as "from
> host.mydomain.com (localhost [127.0.0.1])by host.mydomain.com
> (8.13.8/8.13.8/Submit) with ESMTP id l12345679for ...".
>
> The third stop is the ISP server where it shows as "from
> host.mydomain.com ([my.ip.addr.ess]) by host.mail.myisp.net with ESMTP
> id <20070202123456.WABC123.host.mail.myisp.net@host.m ydomain.com> for
> ..."
>
> After that, there is no reference to host.mydomain.com in the header.

Before you start down this road, I think you should stop and try something else first. What you are talking about is down stream servers doing header analysis on content that is not from the server they received the message(s) from. I'm not going to say that this does not happen, but it *SHOULD NOT* (with all RFC implied meaning there) happen.

> I suspect, and it is only a WAG, that the
> "<20070202123456.WABC123.host.mail.myisp.net@host. mydomain.com>" is the
> problem. I think it is the host.mydomain.com at the end that is
> failing a reverse lookup check for those mail servers that look at the
> originating domain as well as the domain of the mail server that the
> email is arriving from.
>
> I also suspect that I could cure this if I masquerade the envelope so
> that the envelope shows a domain of myisp.net when it leaves my server.
> After doing some reading it would appear that one of way of doing this
> is using "FEATURE(genericstable)", but that also appears to require
> that an entry has to be made for each user, including new users.

Wow, slow down there. (See below)

> 1. What are the chances that my analysis is correct?

I think you are prematurely jumping to conclusions before you exhaust all possible tests that you can do.

> 2. If it is correct, is there a one time cure for the entire domain
> rather than on a user by user basis?

If you do make changes, they should be domain wide, probably sending rather than receiving.

> 3. If it is not correct, do you have any suggestions on what the
> problem might be?

No, not off hand.

What I think you need to do is manually send a message with Message Disposition Notification options. With MDN, you can request the destination server or the last server in the chain that supports / honors MDN requests to send you notification when the message is received. For example:



EHLO <FQDN of client>
250 ...
MAIL FROM:<your_email_address@your_domain.tld> RET=HDRS ENVID=test_1
250 ...
RCPT TO:<suspect_email_address@fqdn.tld> NOTIFY=SUCCESS,FAILURE,DELAY ORCPT=rfc822;<suspect_email_address@fqdn.tld>
250 ...
DATA
....
..
250 ...
QUIT
221 ...



This will cause the last server in the chain of servers that supports MDN to return a message like this:



--l12FugHO021965.1170431802/rti02.co-lo.riverviewtech.net

The original message was received at Fri, 2 Feb 2007 09:56:34 -0600
from localhost [127.0.0.1]

----- The following addresses had successful delivery notifications -----
<suspect_email_address@fqdn.tld> (successfully delivered to mailbox)

----- Transcript of session follows -----
<suspect_email_address@fqdn.tld>... Successfully delivered

--l12FugHO021965.1170431802/rti02.co-lo.riverviewtech.net
Content-Type: message/delivery-status

Original-Envelope-Id: test_2
Reporting-MTA: dns; rti02.co-lo.riverviewtech.net
Received-From-MTA: DNS; localhost
Arrival-Date: Fri, 2 Feb 2007 09:56:34 -0600

Original-Recipient: rfc822;suspect_email_address@fqdn.tld
Final-Recipient: RFC822; suspect_email_address@fqdn.tld
X-Actual-Recipient: RFC822; suspect_email_address@fqdn.tld
Action: delivered (to mailbox)
Status: 2.1.5
Diagnostic-Code: SMTP; 250 2.1.5 RCPT ok
Last-Attempt-Date: Fri, 2 Feb 2007 09:56:42 -0600

--l12FugHO021965.1170431802/rti02.co-lo.riverviewtech.net
Content-Type: text/rfc822-headers

.... original message headers here ...

--l12FugHO021965.1170431802/rti02.co-lo.riverviewtech.net--



As you can see, this MDN is from the destination mail server. It states an action of "delivered", which means it made it in to the destination mail box. There is a lot of other diagnostic in formation that will you find out where problems are along the way.

I hope this s you by providing more diagnostic information. I expect that you will find that messages are making it through the chain of server to a server, probably closer to the destination, that did something with the message. I will say that some email administrators turn of MDNs for some strange reason about like some administrators turn off DSNs or refuse to accept the null reverse path email address <>. *SIGH* The actions of such administrators make the work of the rest of us a lot harder. Fortunately for us, if a destination server does not honor MDNs, the server sending the message to it will send a MDN to the sender stating that the message was relayed. This MDN in and of it's self will provide a destination server to question and thus an organization to contact and way "WTF???".



Grant. . . .

In article
<mailman.148.1170432975.28999.comp.mail.sendmail@m aillists.riverviewtech.net>
Grant Taylor <gtaylor@riverviewtech.net> writes:
>> The third stop is the ISP server where it shows as "from
>> host.mydomain.com ([my.ip.addr.ess]) by host.mail.myisp.net with ESMTP
>> id <20070202123456.WABC123.host.mail.myisp.net@host.m ydomain.com> for
>> ..."
>>
>> After that, there is no reference to host.mydomain.com in the header.
>
>Before you start down this road, I think you should stop and try
>something else first. What you are talking about is down stream servers
>doing header analysis on content that is not from the server they
>received the message(s) from. I'm not going to say that this does not
>happen, but it *SHOULD NOT* (with all RFC implied meaning there) happen.

In particular it's (almost:-) unthinkable that any server would try to
lookup any part of the *id* in a Received header - that's a totally
arbitrary string that isn't expected to have any meaning to anyone
except the MTA that generated that Received header. But there are lots
of broken things done in the name of "spam fighting".

>What I think you need to do is manually send a message with Message
>Disposition Notification options. With MDN, you can request the
>destination server or the last server in the chain that supports /
>honors MDN requests to send you notification when the message is
>received. For example:
>
>
>
>EHLO <FQDN of client>
>250 ...
>MAIL FROM:<your_email_address@your_domain.tld> RET=HDRS ENVID=test_1
>250 ...
>RCPT TO:<suspect_email_address@fqdn.tld> NOTIFY=SUCCESS,FAILURE,DELAY
>ORCPT=rfc822;<suspect_email_address@fqdn.tld>

s/MDN/DSN/g. MDNs are end-user things, for the recipient's MUA to
potentially generate, requested via a Disposition-Notification-To
header. DSNs are MTA things, requested via the NOTIFY option to RCPT (or
generated without request in the FAILURE/DELAY cases).

--Per Hedeland
per@hedeland.org

In article
<mailman.148.1170432975.28999.comp.mail.sendmail@m aillists.riverviewtec
h.net>, gtaylor@riverviewtech.net says...
> HSD wrote:
> > I have configured an email server using sendmail-8.13.8 on Slackware
> > 11.0 for a domain using dynamic DNS. I route external mail leaving the
> > server through my ISP since mail leaving the server directly often
> > bounces because the reverse lookup at the other end doesn't match
> > mydomain.com. For 99% of the time, relaying through my ISP works fine,
> > but for two domains that I want to deliver mail to, it doesn't appear
> > to work. The mail doesn't bounce, it just goes out never to be seen
> > again.
>
> It's always nice to see a fellow Slack'er. That's no good on the email though. We use to be able to say that email would either arrive, or you would get bounce. However, now with all the other imitation MTAs on the market, sadly we can no longer say that.
>

I have been using Slackware a little over ten years now. I first
picked it for a web server at work because it seemed to me to be the
most secure of the Linux distributions available at that time. While I
was responsible for the server (recently retired), it was never broken
into and I attribute that to Slackware, not to me. I always learned
just enough (as this thread proves) to make it work and solve whatever
problem was at hand, and then on to the next project. I am certainly
no expert on Linux.

> > I suspect it is sill a reverse lookup problem. If I look at the
> > headers of the outbound mail, the first stop is the local sever where
> > it shows as "from localhost (username@localhost)by host.mydomain.com
> > (8.13.8/8.13.8/Submit) with ESMTP id l12345678for ...".
> >
> > The second stop is also the local server where it shows as "from
> > host.mydomain.com (localhost [127.0.0.1])by host.mydomain.com
> > (8.13.8/8.13.8/Submit) with ESMTP id l12345679for ...".
> >
> > The third stop is the ISP server where it shows as "from
> > host.mydomain.com ([my.ip.addr.ess]) by host.mail.myisp.net with ESMTP
> > id <20070202123456.WABC123.host.mail.myisp.net@host.m ydomain.com> for
> > ..."
> >
> > After that, there is no reference to host.mydomain.com in the header.
>
> Before you start down this road, I think you should stop and try something else first. What you are talking about is down stream servers doing header analysis on content that is not from the server they received the message(s) from. I'm not going to say that this does not happen, but it *SHOULD NOT* (with all RFC implied meaning there) happen.
>
> > I suspect, and it is only a WAG, that the
> > "<20070202123456.WABC123.host.mail.myisp.net@host. mydomain.com>" is the
> > problem. I think it is the host.mydomain.com at the end that is
> > failing a reverse lookup check for those mail servers that look at the
> > originating domain as well as the domain of the mail server that the
> > email is arriving from.
> >
> > I also suspect that I could cure this if I masquerade the envelope so
> > that the envelope shows a domain of myisp.net when it leaves my server.
> > After doing some reading it would appear that one of way of doing this
> > is using "FEATURE(genericstable)", but that also appears to require
> > that an entry has to be made for each user, including new users.
>
> Wow, slow down there. (See below)
>
> > 1. What are the chances that my analysis is correct?
>
> I think you are prematurely jumping to conclusions before you exhaust all possible tests that you can do.
>
> > 2. If it is correct, is there a one time cure for the entire domain
> > rather than on a user by user basis?
>
> If you do make changes, they should be domain wide, probably sending rather than receiving.
>
> > 3. If it is not correct, do you have any suggestions on what the
> > problem might be?
>
> No, not off hand.
>
> What I think you need to do is manually send a message with Message Disposition Notification options. With MDN, you can request the destination server or the last server in the chain that supports / honors MDN requests to send you notification when the message is received. For example:
>
>
>
> EHLO <FQDN of client>
> 250 ...
> MAIL FROM:<your_email_address@your_domain.tld> RET=HDRS ENVID=test_1
> 250 ...
> RCPT TO:<suspect_email_address@fqdn.tld> NOTIFY=SUCCESS,FAILURE,DELAY ORCPT=rfc822;<suspect_email_address@fqdn.tld>
> 250 ...
> DATA
> ...
> .
> 250 ...
> QUIT
> 221 ...
>

On the first one, a pseudo government agency that uses an ISP for
email, I received a receipt back indicating that the email was accepted
at the destination mail server and that the user was valid. That is
probably the reason I never received a reject message on previous
emails. I will have to check with the individual on Monday when they
arrive at work to see if it is actually in their mailbox. If they do
not have it, it must be the result of some sort of filtering by the
mail server after it arrives.

The second one was sent to an actual state government agency (.us TLD)
that uses state government networks and mail servers, and so far (12+
hours) no receipt, failure, or delay notice. I also sent a third
email to another user name in the same domain with the same result. I
am sure the mail went out with the DSN request because the maillog has
a line entry of "DSN: Return receipt" for those particular emails.

I will give it some more time, but I suspect I never will get an
acknowledgment one way or the other. I think the agency mail server
accepted it, and dropped it - the end.

It appears I might be back to trying to change the envelope (sigh) as a
possible solution unless you have some other ideas.

Thanks.

>
>
> This will cause the last server in the chain of servers that supports MDN to return a message like this:
>
>
>
> --l12FugHO021965.1170431802/rti02.co-lo.riverviewtech.net
>
> The original message was received at Fri, 2 Feb 2007 09:56:34 -0600
> from localhost [127.0.0.1]
>
> ----- The following addresses had successful delivery notifications -----
> <suspect_email_address@fqdn.tld> (successfully delivered to mailbox)
>
> ----- Transcript of session follows -----
> <suspect_email_address@fqdn.tld>... Successfully delivered
>
> --l12FugHO021965.1170431802/rti02.co-lo.riverviewtech.net
> Content-Type: message/delivery-status
>
> Original-Envelope-Id: test_2
> Reporting-MTA: dns; rti02.co-lo.riverviewtech.net
> Received-From-MTA: DNS; localhost
> Arrival-Date: Fri, 2 Feb 2007 09:56:34 -0600

On 02/03/07 15:03, HSD wrote:
> I have been using Slackware a little over ten years now. I first
> picked it for a web server at work because it seemed to me to be the
> most secure of the Linux distributions available at that time. While I
> was responsible for the server (recently retired), it was never broken
> into and I attribute that to Slackware, not to me. I always learned
> just enough (as this thread proves) to make it work and solve whatever
> problem was at hand, and then on to the next project. I am certainly
> no expert on Linux.

*nod* I did not start using Slack' for that reason. I started using it
because my friend who was trying to get me in to Linux was running it
and handed me a book ("Slackware '96"" and left me to fend for my self.

> On the first one, a pseudo government agency that uses an ISP for
> email, I received a receipt back indicating that the email was accepted
> at the destination mail server and that the user was valid. That is
> probably the reason I never received a reject message on previous
> emails. I will have to check with the individual on Monday when they
> arrive at work to see if it is actually in their mailbox. If they do
> not have it, it must be the result of some sort of filtering by the
> mail server after it arrives.

It is nice to know that your message made it to the destination server
and that the problem is not with delivery methods on your end.

> The second one was sent to an actual state government agency (.us TLD)
> that uses state government networks and mail servers, and so far (12+
> hours) no receipt, failure, or delay notice. I also sent a third
> email to another user name in the same domain with the same result. I
> am sure the mail went out with the DSN request because the maillog has
> a line entry of "DSN: Return receipt" for those particular emails.

I can not say that I'm surprised that a government agency might be doing
some non standard things (filtering / lack of DSN responses) probably
under the guise of security.

> I will give it some more time, but I suspect I never will get an
> acknowledgment one way or the other. I think the agency mail server
> accepted it, and dropped it - the end.

*nod*

> It appears I might be back to trying to change the envelope (sigh) as a
> possible solution unless you have some other ideas.

No, sorry, I don't have any more ideas short of a very basic "This is a
test." type message that should not set off any bells / whistles /
alarms / filters. I think you are going to have to involve the email
administrator of the receiving end to find out what is happening for sure.



Grant. . . .