PHWinfo - Afficher un message

03/02/2007, 22h03

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

03/02/2007, 22h03	#4
HSD Messages: n/a Hébergeur:	Re: Dynamic DNS Problem 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