2

I've had a problem recently with spam coming in with an envelope-from consisting of my own address. At first I thought this meant that my password had been compromised, mistakenly thinking that the "with esmtp (Exim 4.87)" in the "by" clause of my email server's Received header meant that it came over an authenticated connection. My email provider quickly corrected me, that incoming messages come from MTAs, and MTAs do not authenticate when passing along a message. So it could just as easily (and most likely did) come through an open relay, as the IP addresses were all listed on 15 or more blacklists.

When I send mail from Thunderbird, I connect on port 587, and that port requires authentication. If I could look at the headers and see that the connection to my ISP's server was on port 587, then I would know that the sender authenticated, and if it had my own address as its envelope-from, then I would know that my password had been compromised, right? Well I guess any server in the trace can modify the earlier headers, but in these cases there aren't any other servers in the trace. And even if there were, it's not clear why a server would want to modify the port number given in an earlier header.

I tried asking the email provider if they could add the port to their "Received by" clause and didn't get a meaningful response. I googled a bit to see if sendmail had an option to do this but got nowhere. However, I guess the header actually tells me they are using Exim rather than sendmail, and this link shows where the header content is configured in Exim, though it doesn't say how to refer to the incoming port number in the text.

But given that the port number seems to provide some very valuable information to anyone dealing with spam from spoofed senders, I wonder why it isn't included by default.

sootsnoot
  • 395
  • 1
  • 4
  • 12
  • `If I could look at the headers and see that the connection to my ISP's server was on port 587, then I would know that the sender authenticated` - that doesn't exclude the possibility that authenticated email was sent via port 25. – joeqwerty Jul 28 '16 at 00:02
  • @joeqwerty I agree and didn't say that it did - only that for my email provider 587 implies authenticated (any other port authentication unknown). But the accepted answer points out that normally the protocol value provides that information unambiguously: an "a" at the end of smtp means authenticated, no "a" and it wasn't authenticated. – sootsnoot Jul 28 '16 at 01:19
  • Right. I just wanted to point that out. I understood where you were coming from. Cheers. – joeqwerty Jul 28 '16 at 01:20

1 Answers1

4

The port number would not be useful in a Received: line, as there are standard ports for email transport, and using alternate ports is not really possible.

If you want to know if a message was authenticated by some mailer, you can find this information in the Received: line by checking the protocol that it was received with. This starts with "SMTP" and then has extensions added to the beginning and end based on various criteria. If the message was authenticated, it will have an "A" at the end, as specified in RFC 3848. An example:

Received: from pool-70-20-60-215.man.east.myfairpoint.net (pool-70-20-60-215.man.east.myfairpoint.net [70.20.60.215]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.example.com (Postfix) with ESMTPSA id C540E956034; Wed, 27 Jul 2016 18:35:17 +0000 (UTC)
Community
  • 1
Michael Hampton
  • 237,123
  • 42
  • 477
  • 940
  • You're right, by jove! Funny/sad thing is that I had noticed the "a" (authenticated) and sometimes "s" (secure) appended to "smtp" in different headers, and googled for the meaning without finding one so simple as this "intuitively logical" explanation. At the moment I can't find the page I read, but honestly it wasn't a simple explanation :-) – sootsnoot Jul 28 '16 at 01:28