On Sun, Feb 07, 2016 at 01:50:47PM +0200, turha turha wrote: > > [...] > > So smtpd is receiving the email without invalid "To" header, however upon > receiving the email at another mail server for personB the "To" header has > been mangled: > "Person BBBB"@domainA.org > > After some further searching I found this article: > https://poolp.org/0xa86e/Some-OpenSMTPD-overview,-part-3 > > The article mentions: "Then came another complaint: some hackers were > receiving mails from some other hackers ... but the mail had a From header > with the local domain instead of the sender domain." > > My issue seems to be a reverse case of what the article mentions. Looking > at the source in smtp_session.c, "From", "To", "Cc" headers are all > replaced with versions where _LOCAL_ domain is appended, if the email came > from a local mail client I would expect that appending the local domain to > the "To" and "Cc" fields would be the wrong course of action. >
Yes, however reality is a bit different: - many MX do not accept that From / To / Cc headers don't have domains; - and when they find one, they WILL append their own domain; So if you're not appending domain yourself, then you have a chance that the next node to receive your message will append its own down, and since there is a chance that it will forward the mail elsewhere, the destination gets a mail with completely bogus headers. Here's an example of how this can happen: - imagine you have a mail server at mx1.opensmtpd.org and imagines that all it does is accept mail that gets ~/.forward-ed - now imagine [email protected] and [email protected] are exchanging mail, but they both use Outlook and the MTA at mx1.opensmtpd.org doesn't do append, whereas the destinations for @faurot.net and @poolp.org do. 1- Eric sends a mail to gilles: From: eric To: gilles 2- mx1.opensmtpd.org receives and doesn't touch the header: 3- mx1.poolp.org receives and appends domains: From: [email protected] To: [email protected] Now gilles replies: From: gilles To: eric 2- mx1.opensmtpd.org receives and doesn't touch the header: 3- mx1.faurot.net receives and appends domains: From: [email protected] To: [email protected] If the MTA checks that user-parts for local domains exist, you have a chance that mail will get rejected at the destination. And if there is a gilles@ at faurot.net, eric will assume the mail came from the local user, when it came from a different gilles ... There are many other weird cases like this if you involve backup MX, hubs or throw mixes of MX that do and don't append domains. If you intend to send to remote hosts, appending local domains (including if it is incorrect) is just a better choice than what will result if you don't. Maybe we should add a method to enable/disable this per admin-request but it is not going to make it into next release as we're way too close to it now. > PS. Regarding the quote from the article, I didn't fully understand why the > "From" header would ever incorrectly have the local domain.. I mean, if > OpenSMTPD prior to the fix mentioned in the article did not mangle the DATA > section, then how could the "From" header which is in the DATA section > accidentally have the local domain appended? > Well simple: 1- setup a mail server for your friends and use a MTA that doesn't append 2- have all your friends setup a ~/.forward file 3- chances are your friends are running Sendmail or Postfix with append 4- whenever a friends mail another and there's no domain in headers, the recipient will see his local domain for all addresses (same as above). > PPS. Is there a reason the default smtpd in OpenBSD 5.8 is OpenSMTPD 5.4.4? > That seems to be from Dec 2014.. > Yes, the work done to implement the filters layer was very invasive and took more than 3 OpenBSD release cycles, so it was worked off-tree. The version in OpenBSD is 5.4.4 + all security/reliability fixes backported just not the new features. We have managed to merge back all changes to OpenBSD so next release is going to ship with latest version again. -- Gilles Chehade https://www.poolp.org @poolpOrg -- You received this mail because you are subscribed to [email protected] To unsubscribe, send a mail to: [email protected]
