Thanks Dan (and everyone else),
Then it is still a mystery to me, because there is no record in the
log of the dell server even attempting a connection to mine. It is
possible, I supposed, that the Dell rep made 4 consecutive typos on 3
different addresses... Even though he insists he didn't, and he got
to me via normal email just fine...
But I understand your point.
Thank you.
Chris
Quoting Dan Harnett <dan...@harnett.name>:
On Thu, Jan 29, 2009 at 09:57:26AM -0500, Chris Ditri wrote:
Wait... I get it now. I did some more reading. The dell server is
trying to send the message to my server encrypted, it gets to my
The part of the log you pasted was an outgoing connection from your
server. If it was incoming, then you would see "STARTTLS=server".
You're barking up the wrong tree. The only relevance that snippet may
have is that something was sent to Dell's server (possible bounce, virus
warning, etc).
server, my server has a self-signed certificate and because of this,
the transaction fails. According to what I'm reading here
(http://www.ietf.org/rfc/rfc2487.txt and
http://www.sendmail.org/~ca/email/starttls.html), if I had my
certificate signed, the two servers would have been able to negotiate
a connection, and it would probably go through.
There hasn't been any indication that the message didn't go through.
The certificate that failed verification was Dell's, not yours. Either
you don't have a proper chain of trust setup, or Dell is using a
certificate in which you do not have the signer's public certificate
(self-signed, oddball unpopular company, etc).
So I am not misconfigured, I'm just not set up to receive this sort of
communication...
Failing the certificate verification won't necessarily prevent the
encryption or the delivery. It's just an indicator that you shouldn't
place any trust the communication channel. You can configure sendmail
not to even bother trying to verify via the access map or the
configuration file.
An example for the access map. This will enable verification for hosts
that resolve to 'my.domain', but not for anyone else. Note that it will
not prevent delivery should the certificates in 'my.domain' fail
verification.
Srv_Features:my.domain v
Srv_Features: V
If you think you're having an issue with STARTTLS when communication
with Dell (which you haven't shown any indication of), then you can also
do something like this in the access map to disable it.
Try_TLS:smtp.ins.dell.com NO
Try_TLS:smtp2.ins.dell.com NO
Most of this is covered in /usr/share/sendmail/README.
--
Reduce spam! Please send emails directly to an email address only from your
trusted email service -- Please do not enter a friend's email address
on any web
site (such as tagged, any "e-card", or anything similar to "mail to a
friend").
Respectable sites will not ask you for your friend's and family's
email addresses.
