Sendmail on Redhat 6.5

[jpra....@gmail.com]

Hi, got an issue with a new redhat 6.5 installation we've got. I'm trying to get the mail relay server option to work by specifying my mail relay server with the DS value. I've tried the FQDN, short hostnames, IP addresses, all the previous in square brackets and nothing works. I've got several hundred other servers were this works, but they are all redhat 5.X.

HAs something fundamental changed in sendmail? I really am stuck with this one now :(

[Claus Aßmann]

wrote:

> Hi, got an issue with a new redhat 6.5 installation we've got. I'm trying to get the mail
> relay server option to work by specifying my mail relay server with the DS value. I've
> tried the FQDN, short hostnames, IP addresses, all the previous in square brackets and
> nothing works. I've got several hundred other servers were this works, but they are all

"nothing works" is a fairly useless problem description.

Please be specific:
what exactly did you do?
what happened (log entries? verbose mailing?)
what did you expect to happen?

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

[jpra....@gmail.com]

Hi, thanks for replying. By nothing works I meant that everything I tried to change in sendmail.cf had no effect.

I tried specifying for the DS variable:

Fully Qualified Domain Name
[FQDN in square brackets]
IP address
[IP in square brackets]

I've also tried disabling postfix, removing postfix, re-applying sendmail rpms. If I run "telnet smartrelay 25" it works, so comms is fine.

We have about 200 linux boxes on this estate, I also tried using a sendmail.cf from one that works but this also doesn't work.

If I mail root@localhost" it all works as expected.

We have several scripts setup that use the following mail command:

mail -s "Subject" us...@domain.com -c another us...@domain.com -- -f host...@clientsdomain.com

This results in the following being bounced back:

Message 2:
From MAILER...@hostname.blah.blah Tue Apr 21 17:07:58 2015
Return-Path: <MAILER...@hostname.blah.blah>
Date: Tue, 21 Apr 2015 17:07:58 +0100
From: Mail Delivery Subsystem <MAILER...@hostname.blah.blah>
To: ro...@hostname.blah.blah
Content-Type: multipart/report; report-type=delivery-status;
boundary="t3LG5R9o017225.1429632478/hostname.blah.blah"
Subject: Returned mail: see transcript for details
Auto-Submitted: auto-generated (failure)
Status: RO

Part 1:

The original message was received at Tue, 21 Apr 2015 17:05:27 +0100
from root@localhost

----- The following addresses had permanent fatal errors -----
-c
(reason: 550 5.1.1 <-...@hostname.blah.blah>... User unknown)
(expanded from: -c)
-f
(reason: 550 5.1.1 <-...@hostname.blah.blah>... User unknown)
(expanded from: -f)

----- Transcript of session follows -----
451 remotehost.com: Name server timeout
451 anotherremote.com: Name server timeout
... while talking to [127.0.0.1]:
>>> DATA
<<< 550 5.1.1 <-...@hostname.blah.blah>... User unknown
550 5.1.1 -f... User unknown
<<< 550 5.1.1 <-...@hostname.blah.blah>... User unknown
550 5.1.1 -c... User unknown
451 remotehost.com: Name server timeout
451 anotherremote.com: Name server timeout

Part 2:
Content-Type: message/delivery-status


Part 3:
Content-Type: message/rfc822

From root Tue Apr 21 17:05:27 2015
Return-Path: <root>
From: root <root>
Date: Tue, 21 Apr 2015 17:05:27 +0100

Any suggestions gratefully received as I'm beginning to loose the will to live with this one...

[Carl Byington]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 22 Apr 2015 10:12:41 -0700, jpra.baker wrote:

> mail -s "Subject" us...@domain.com -c another us...@domain.com -- -f
> host...@clientsdomain.com

> This results in the following being bounced back:

The 'mail' command is part of the mailx package, having nothing to do
with sendmail. There are significant differences between the RH5 and RH6
versions of that command.

All the switches, -s, -c, -f etc are supposed to be before the target
user, although on a RH5 box, those switches take effect even after the
target address.

You might try something like:

cat message | mail -s subject -c ccu...@example.com \
-r sen...@example.com tar...@example.com


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEARECAAYFAlU4PtoACgkQL6j7milTFsHSFQCbBwBjQOvyBmdIPj/AOujzEYrv
8V0An0FyZkI5tyXrII4zrWOzV+vHMcC8
=Xv6x
-----END PGP SIGNATURE-----

[Claus Aßmann]

wrote:

> I tried specifying for the DS variable:

> Fully Qualified Domain Name
> [FQDN in square brackets]
> IP address
> [IP in square brackets]

Please provide real data.

> 451 remotehost.com: Name server timeout
> 451 anotherremote.com: Name server timeout

So now we don't have the slightest idea what relation
Fully Qualified Domain Name
has with
remotehost.com
anotherremote.com

Maybe you should fix DNS?
BTW: if this is sendmail 8.15, you should really read the release
notes -- there is an important change.


And if you want to test your sendmail setup, use sendmail... not some
other command that maybe invokes sendmail with wrong parameters...

# date | sendmail -v -Am yo...@email.address

[Tim Daneliuk]

On 04/22/2015 08:01 PM, Claus Aßmann wrote:
> BTW: if this is sendmail 8.15, you should really read the release
> notes -- there is an important change.

The important change affects on IPV6 addresses, correct, or is there something
else you had in mind? i.e., There is nothing in 8.15 that breaks existing
IPV4 configurations...?

--
----------------------------------------------------------------------------
Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/

[Claus Aßmann]

This is the item that so far caused the most questions
(due to temporary DNS problems):

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.

[Tim Daneliuk]

So, if understand this correctly, outbound SMTP will not get delivered until
it can resolve map lookups (either immediately or as later deferred) or
until the retry period expires and that mail delivery fails hard.

Is this correct? Can you provide some insight into the motivation for this
change?

Thanks, (as always)

[Claus Aßmann]

Tim Daneliuk wrote:
> On 04/23/2015 10:23 AM, Claus Aßmann wrote:

> > If header rewriting fails due to a temporary map lookup failure,

> Is this correct? Can you provide some insight into the motivation for this
> change?

Sorry, but is that really a serious question?
It's obviously a bug fix...

What should an MTA do if it encounters a temporary failure
(unless explicitly told to ignore it)?

[Tim Daneliuk]

On 04/26/2015 10:07 AM, Claus Aßmann wrote:
> Tim Daneliuk wrote:
>> On 04/23/2015 10:23 AM, Claus Aßmann wrote:
>
>>> If header rewriting fails due to a temporary map lookup failure,
>
>> Is this correct? Can you provide some insight into the motivation for this
>> change?
>
> Sorry, but is that really a serious question?
> It's obviously a bug fix...
>
> What should an MTA do if it encounters a temporary failure
> (unless explicitly told to ignore it)?
>
>

I guess my real question is - why was it ever anything other than the
current behavior? What historically was the motive for a header rewrite
and delivery?