Avoiding "may be forged" warnings for authenticated SMTP connections
Greg Hurrell
outgoing mail to have "may be forged" warnings inserted into the
headers. I'm sending via authenticated SMTP with SSL/TLS and see
messages like this in the logs:
STARTTLS=server, relay=131.115.217.87.dynamic.jazztel.es
[87.217.115.131] (may be forged), version=TLSv1/SSLv3, verify=NO,
cipher=AES128-SHA, bits=128/128
Evidently the problem is caused because a lookup on my IP,
87.217.115.131, yields the hostname "131.115.217.87.dynamic.jazztel.es"
but doing a reverse lookup on that hostname yields nothing at all.
I am going to ask my provider, Jazztel, to fix their DNS, but I am not
hopeful that they will do much about it. I am wondering if anyone has a
suggestion for avoiding these warnings. I'd like to clean them up
because I suspect that this might be making my messages look spammier
than they are. One of the reasons why I run my own mail server is
precisely to avoid the kind of problem that arises from sending from a
dynamic IP address.
Thanks in advance,
Greg.
PS. I'm running sendmail 8.12.11.20060308 on Red Hat Enterprise Linux
ES release 3
Josh Grosse
> I've just noticed that my ISP's DNS set-up is causing all of my
> outgoing mail to have "may be forged" warnings inserted into the
> headers.
Have you tried smarthosting? e.g.:
define(`SMART_HOST', `smtp.jazztel.es')dnl
In this way, all of your outgoing mail goes through your ISP, and will
look less spammy.
--
Replying directly will get you locally blacklisted.
Change the address; use my first name in front of the @ if you want to
communicate privately.
Greg Hurrell
> On Thu, 04 Jan 2007 11:07:05 -0800, Greg Hurrell wrote:
>
> > I've just noticed that my ISP's DNS set-up is causing all of my
> > outgoing mail to have "may be forged" warnings inserted into the
> > headers.
>
> Have you tried smarthosting? e.g.:
>
> define(`SMART_HOST', `smtp.jazztel.es')dnl
>
> In this way, all of your outgoing mail goes through your ISP, and will
> look less spammy.
Ok, thanks for the suggestion. I will do some research on smarthosting
and decide whether it is right for me. So far have found this (question
3.44 in the FAQ):
"This has the advantage that you don't have to run a daemon on the
local host, but a disadvantage of introducing a dependency on the
smart_host machine. Which of the two solutions is better for you
depends on whether or not your network architecture has such a
smart_host, how reliable you deem that smart_host to be, and how
inconvenient running a daemon locally would be."
http://www.sendmail.org/faq/section3.html
And this page also has a section on smart hosts:
NPG
> I've just noticed that my ISP's DNS set-up is causing all of my
> outgoing mail to have "may be forged" warnings inserted into the
> headers. I'm sending via authenticated SMTP with SSL/TLS and see
> messages like this in the logs:
>
> STARTTLS=server, relay=131.115.217.87.dynamic.jazztel.es
> [87.217.115.131] (may be forged), version=TLSv1/SSLv3, verify=NO,
> cipher=AES128-SHA, bits=128/128
>
> Evidently the problem is caused because a lookup on my IP,
> 87.217.115.131, yields the hostname "131.115.217.87.dynamic.jazztel.es"
> but doing a reverse lookup on that hostname yields nothing at all.
>
> I am going to ask my provider, Jazztel, to fix their DNS
, but I am not
> hopeful that they will do much about it. I am wondering if anyone has a
> suggestion for avoiding these warnings. I'd like to clean them up
> because I suspect that this might be making my messages look spammier
> than they are.
One of the reasons why I run my own mail server is
> precisely to avoid the kind of problem that arises from sending from a
> dynamic IP address.
appears to be dynamic.
When you run your own mail server, you are responsible ( fully or in
part ) for what address it uses, and for making sure that its DNS is set
up correctly in both directions.
Greg Hurrell
> > One of the reasons why I run my own mail server is
> > precisely to avoid the kind of problem that arises from sending from a
> > dynamic IP address.
>
> Which is why that address is already listed at sorbs.net, because it
> appears to be dynamic.
> When you run your own mail server, you are responsible ( fully or in
> part ) for what address it uses, and for making sure that its DNS is set
> up correctly in both directions.
Perhaps I didn't explain my set-up correctly. My mail server *is*
correctly set up and DNS look-ups *do* resolve correctly in both
directions. The problem is that when I connect to the mail server from
home using my (dynamic IP) ADSL connection, I get those unwanted "may
be forged" warnings in *one* of the "Received:" headers of my mails
(the one that corresponds to my mail application at home connecting to
my mail server). I have no control over my ISP's DNS, and I have no
control over what IP they assign to my ADSL connection at any given
moment, although as I stated earlier I have asked them to fix the
reverse lookups on their DNS.
I am not running a mail server on my local machine; I am running
Mail.app on Mac OS X. My mail application connects to my mail server
via SSL/TLS and the connection is made using authenticated SMTP. The
problem is illustrated by the following headers from a test message
that I mailed to myself.
The headers are in last-to-first order, so starting from the top you
see the "Received" headers of the Gmail servers. The third such header
you see describes the hop from my mail server to mx.google.com. You'll
also see an SPF header which shows that my server has SPF records
correctly set up. But check out the last header; that's the one that
corresponds to my initial connection from home to my mailserver, and
that's the one with the "may be forged" warning.
Received: by 10.70.63.14 with SMTP id l14cs118631wxa;
Sat, 6 Jan 2007 04:10:48 -0800 (PST)
Received: by 10.100.45.10 with SMTP id s10mr17721170ans.1168085448427;
Sat, 06 Jan 2007 04:10:48 -0800 (PST)
Return-Path: <gr...@greghurrell.net>
Received: from s69819.wincent.com (wincent.com [72.3.236.74])
by mx.google.com with ESMTP id
d35si17614857and.2007.01.06.04.10.47;
Sat, 06 Jan 2007 04:10:48 -0800 (PST)
Received-SPF: pass (google.com: domain of gr...@greghurrell.net
designates 72.3.236.74 as permitted sender)
Received: from [192.168.1.128] (254.114.217.87.dynamic.jazztel.es
[87.217.114.254] (may be forged))
(authenticated bits=0)
by s69819.wincent.com (8.12.11.20060308/8.12.11) with ESMTP id
l06CAj0Y017631
(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO)
for <greg.h...@gmail.com>; Sat, 6 Jan 2007 06:10:46 -0600
The other thing about that header is that it shows the internal IP
address of my LAN (192.168.1.128) as well as the external address
87.217.114.254; I have no idea why it exposes that information.
Kari Hurtta
That [192.168.1.128] was something what your mail application used
on ehlo or helo -command:
EHLO [192.168.1.128]
/ Kari Hurtta
Bill Cole
"Greg Hurrell" <greg.h...@gmail.com> wrote:
[...]
> I am not running a mail server on my local machine; I am running
> Mail.app on Mac OS X. My mail application connects to my mail server
> via SSL/TLS and the connection is made using authenticated SMTP. The
> problem is illustrated by the following headers from a test message
> that I mailed to myself.
Useful!
Having that full information helps feed an explanation. I don't think I
have a solution for you, but maybe I can illuminate what is going on a
little bit. Please note that you really should not need to worry about
all of this, since
Snipping down to just the Received header that your Sendmail mail server
is adding:
> Received: from [192.168.1.128] (254.114.217.87.dynamic.jazztel.es
> [87.217.114.254] (may be forged))
> (authenticated bits=0)
> by s69819.wincent.com (8.12.11.20060308/8.12.11) with ESMTP id
> l06CAj0Y017631
> (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO)
> for <greg.h...@gmail.com>; Sat, 6 Jan 2007 06:10:46 -0600
>
> The other thing about that header is that it shows the internal IP
> address of my LAN (192.168.1.128) as well as the external address
> 87.217.114.254; I have no idea why it exposes that information.
There are really multiple issues here.
1. Mail.app does not know how to introduce itself with anything other
than a bracketed IP literal. The first thing it is telling your Sendmail
after getting the TLS session started is 'EHLO [192.168.1.128]' and
Sendmail is dutifully putting that into the Received header it builds.
To fix that, you would need to figure out how to get Mail.app to use
something like a valid name or the external IP in its introduction. I
run MacOS X but don't use Mail.app, so I don't have any clues on how to
do that. You could ask Apple, but don't expect a solution. This is
actually a hard problem to solve short of having an arbitrary user
setting, and that tends to confuse more people than it helps. In any
case, it isn't a huge issue because all it does is expose the fact that
you are using a particular RFC1918 address internally, and that's not a
secret worth the trouble of keeping. This sort of problem is precisely
why RFC2821 allows IP literals as the HELO/EHLO string and warns against
trying to validate that identity.
2. The 'may be forged' part is due to your IP address having a PTR
record pointing to a name that definitively does not exist.
This is because Jazz Telecom is operated by people who should not be
allowed anywhere near a DNS server. They have published such bogus PTR
records for their address space for years. That is gross incompetence
bordering on fraud. Sadly, their major competition is from entities like
Telefonica and Wanadoo who are similarly clueless or worse so it isn't
very useful to recommend changing providers. If you can get them to do
the right thing with their DNS, I'd be quite impressed. If you can find
an alternative provider with less of a clue deficit, you should consider
changing.
Your options for spackling over your ISP's cranial gap are limited,
unpleasant, and all arguably wrong in some way (hence the metaphor...):
A. You could reconfigure Sendmail's Received header template in
sendmail.cf to not include all that info, but if your machine is doing
anything more than handling your outbound mail that's a poor choice.
B. You could hack the Sendmail code to not include the bogus PTR warning
or to rephrase it. That's not as hard as it sounds, since you should be
able to just replace 'may be forged' with some other string in
sendmail/daemon.c and rebuild. On the other hand, it seems likely from
your first post that you're using a prebuilt Sendmail binary, so this
drags in the whole learning process of how to build Sendmail...
C. Avoid asking the real nameservers at Jazz about their names and
addresses, since they can't tell you a consistent set of lies:
(1) If you keep the same address for extended periods, you could
add that address to /etc/hosts on the Sendmail machine so that
it is known without talking to DNS. This requires a change every
(2) If you run your own DNS server that does resolution for your
mail server, you could make it authoritative for a chunk of
IP address space including the addresses you get from Jazz
(i.e. 114.217.87.in-addr.arpa or maybe more) or for the names
that Jazz has in their PTR's but which don't resolve forward
(i.e. dynamic.jazztel.es or maybe a narrower subdomain) This
requires that you have a better understanding of DNS than
Jazz, which actually is a much lower hurdle than it should be.
--
Now where did I hide that website...
NPG
>
> Perhaps I didn't explain my set-up correctly. My mail server *is*
> correctly set up and DNS look-ups *do* resolve correctly in both
> directions. The problem is that when I connect to the mail server from
> home using my (dynamic IP) ADSL connection, I get those unwanted "may
> be forged" warnings in *one* of the "Received:" headers of my mails
> (the one that corresponds to my mail application at home connecting to
> my mail server). I have no control over my ISP's DNS, and I have no
> control over what IP they assign to my ADSL connection at any given
> moment, although as I stated earlier I have asked them to fix the
> reverse lookups on their DNS.
>
> I am not running a mail server on my local machine; I am running
> Mail.app on Mac OS X. My mail application connects to my mail server
> via SSL/TLS and the connection is made using authenticated SMTP.
>
NPG
Greg Hurrell
> Having that full information helps feed an explanation. I don't think I
> have a solution for you, but maybe I can illuminate what is going on a
> little bit.
Thanks, Bill. Your reply has pretty much covered all bases of this
topic! Thanks for sharing your expertise.
I have yet to receive a reply from the ISP about their bad DNS and
won't be surprised if I never do, but it's worth at least asking.
:-)
Greg
Grant Taylor
> Received: from [192.168.1.128] (254.114.217.87.dynamic.jazztel.es
> [87.217.114.254] (may be forged))
> (authenticated bits=0)
> by s69819.wincent.com (8.12.11.20060308/8.12.11) with ESMTP id
> l06CAj0Y017631
> (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO)
> for <greg.h...@gmail.com>; Sat, 6 Jan 2007 06:10:46 -0600
Consider looking in to SSH port forwarding. If you could SSH in to your
mail server, you can redirect local port 25 / 587 to your real server's
port 25 / 587. This should make your mail server think that the
connection is coming directly in to it. I might suggest that you use
127.0.0.1 verses the external globally routable IP.
I just established an SSH connection from my workstation here at home to
my mail server via the following command line:
ssh -L 25:127.0.0.1:25 rti02.co-lo.riverviewtech.net
My corresponding Received header is included below:
Received: from localhost (localhost [127.0.0.1])
by rti02.co-lo.riverviewtech.net (8.13.8/8.13.8) with ESMTP id
l093PQME005067 for <gtaylor...@riverviewtech.net>;
Mon, 8 Jan 2007 21:26:07 -0600
So, this *MAY* be a workaround for you.
Grant. . . .
Greg Hurrell
>
> Consider looking in to SSH port forwarding. If you could SSH in to your
> mail server, you can redirect local port 25 / 587 to your real server's
> port 25 / 587. This should make your mail server think that the
> connection is coming directly in to it. I might suggest that you use
> 127.0.0.1 verses the external globally routable IP.
>
Thanks, Grant. That would definitely work. I'll think about doing that
if I don't hear back from the ISP (and still haven't heard yet,
unsurprisingly).
Cheers,
Greg
Greg Hurrell
> Thanks, Grant. That would definitely work. I'll think about doing that
> if I don't hear back from the ISP (and still haven't heard yet,
> unsurprisingly).
Just for the record, several weeks have passed since I contacted my ISP
(Jazztel) and finally yesterday I got an email from them acknowledging
receipt of my message. Looks like my query had been bounced around from
department to department and nobody knew how to handle it.
So today I get a phone call from Jazztel and it's a pleasant and
helpful phone operator who evidently doesn't understand the problem.
She did the usual stuff (getting me to login to my router, check the
settings, checking my network configuration etc); I patiently obliged
and then tried to explain to her the real nature of the problem: that
my machine is working fine, that DNS lookups are working, that I have
no trouble navigating the web, no trouble sending or receiving email,
BUT that their DNS is misconfigured because it doesn't provide reverse
lookups for dynamic IPs...
$host 87.217.115.102
102.115.217.87.in-addr.arpa domain name pointer
102.115.217.87.dynamic.jazztel.es.
$ host 102.115.217.87.dynamic.jazztel.es
Host 102.115.217.87.dynamic.jazztel.es not found: 3(NXDOMAIN)
I really have no idea if she actually understood what I was talking
about. She said they'd get back in touch with me. Can anybody point me
to an authoritative document (preferably an RFC) that I could ask them
to look at rather than trying to explain this myself? I was thinking
that RFC 1912 ("Common DNS Operational and Configuration Errors"),
might be the one... maybe RFC 3172?
Greg
Andrzej Adam Filip
Or you may use "ssh mailer":
http://anfi.homeunix.net/sendmail/ssh.html
It makes your local sendmail pass message to "sendmail -bs"
(SMTP over stdin/stdount) executed by ssh on remote host.
WARNING: The above mailer was designed for "low volume" sending.
--
[pl>en: Andrew] Andrzej Adam Filip : an...@priv.onet.pl : an...@xl.wp.pl
Before You Ask: http://anfi.homeunix.net/sendmail/B4UAsk-Sendmail.html
http://anfi.homeunix.net/sendmail/ [orkut,linkedin,xing]
Greg Hurrell
> She said they'd get back in touch with me.
Just got another phone call from Jazztel in which she tried to tell me
that there were probably configuration errors with "the other servers"
(ie. not Jazztels); she also tried to tell me that if I couldn't do
reverse lookups it was probably because I had been "blocked" from doing
such lookups (evidently not true, see below); finally she told me that
it was almost certain that they wouldn't change the DNS because it
could "impact" other customers.
So I again tried to explain to her what the problem was and what I was
asking but she just didn't seem to get it. She said she'd leave the
issue open but I am not too hopeful. I think I'd have to put it in
writing with a lot of really solid documentation to back me up to have
even a snowball's chance in hell of getting Jazztel to fix their DNS.
I'd love to be able to just say "Bill on comp.mail.sendmail said":
> This is because Jazz Telecom is operated by people who should not be
> allowed anywhere near a DNS server. They have published such bogus PTR
> records for their address space for years. That is gross incompetence
> bordering on fraud
But somehow I don't think that will be enough to convince them... ;-)
Note that reverse lookups work for their website:
$ host www.jazztel.es
www.jazztel.es has address 212.106.192.74
$ host 212.106.192.74
74.192.106.212.in-addr.arpa domain name pointer www.jazztel.es.
But they don't even work for their primary DNS server (87.216.1.65):
$ host 87.216.1.65
65.1.216.87.in-addr.arpa domain name pointer
65.1.216.87.static.jazztel.es.
$ host 65.1.216.87.static.jazztel.es
Host 65.1.216.87.static.jazztel.es not found: 3(NXDOMAIN)
Per Hedeland
Hurrell" <greg.h...@gmail.com> writes:
>
>$host 87.217.115.102
>102.115.217.87.in-addr.arpa domain name pointer
>102.115.217.87.dynamic.jazztel.es.
>$ host 102.115.217.87.dynamic.jazztel.es
>Host 102.115.217.87.dynamic.jazztel.es not found: 3(NXDOMAIN)
>
>I really have no idea if she actually understood what I was talking
>about. She said they'd get back in touch with me. Can anybody point me
>to an authoritative document (preferably an RFC) that I could ask them
>to look at rather than trying to explain this myself? I was thinking
>that RFC 1912 ("Common DNS Operational and Configuration Errors"),
>might be the one... maybe RFC 3172?
1912 would be the one - there is no formal/"standard" requirement to
have any DNS records at all, or if you have some, that they are
consistent - but 1912 does provide some form of "best practice"
consensus, and an RFC number is always impressive.:-) One has to wonder
why they bother setting up PTR records in the first place - if your host
had neither PTR nor A, you wouldn't get the "may be forged"... That
being said, I doubt whether anyone (human or spam filter) actually cares
whether that phrase is present way down in the Received headers - if you
actually were a spammer, you would of course make sure that there were
no headers saying "may be forged"!
--Per Hedeland
p...@hedeland.org
hyc
> Consider looking in to SSH port forwarding. If you could SSH in to your
> mail server, you can redirect local port 25 / 587 to your real server's
> port 25 / 587. This should make your mail server think that the
> connection is coming directly in to it. I might suggest that you use
> 127.0.0.1 verses the external globally routable IP.
I used to do that, now I use stunnel so I don't have to ssh login to
my mail server before sending mail.
-- Howard