Postfix/Exim sender address rewriting (was: Postfix ... ComCast port 587)

Ben Scott dragonhawk at gmail.com
Thu Jan 22 18:43:06 EST 2009


On Thu, Jan 22, 2009 at 11:25 AM, Bill McGonigle <bill at bfccomputing.com> wrote:
> Righto, and certainly you can do that with address rewriting, but why not
> setup the MUA properly in the first place?

  For traditional Unix systems, the MUA is not responsible for
building the email address.  That's the job of the MTA (or the MSA if
the system has that concept).  sendmail(1), in other words.  (I'm
talking about "sendmail" the command here, not "Sendmail" the
implementation.)

  As far as "proper" configuration of *that* goes, I think that lying
about one's hostname is not proper.  :)  My hostname is not
"comcast.net", nor does my IP match that domain name.  None of my
account user names are valid email addresses at Comcast.  Most of my
email addresses are not there, either.

  If you really want your MTA's hostname to be proper, you need to
find or create a domain name that matches your IP address, and set
your MTA to use that.  And if you have a dynamic IP address, you'll
have to keep updating one or both.

  That's certainly doable, but I don't think it's worth worrying
about.  As detailed previously, the MTA's hostname really doesn't
matter all that much in this scenario.  The vast majority of Windows
MUAs don't submit with a valid HELO, so any ISP relay filtering on
that is going to block a lot of mail (and thus most likely go out of
business).  And a nominal "MTA" operated for purposes of Mail
Submission is not the same thing as being a Mail Exchanger.  MX'es
should have proper hostnames, so problems where mail routing matters
can be traced.

> I understand your edge case about gmail but I think you can consider
> yourself fortunately unique in that scenario.

  How so?  This is a semi-regular issue on this and other mailing
lists, so apparently people running *nix mailhosts run into the
problem a lot.    It certainly applies to the post which kicked off
this discussion.  :)

  I suppose many people these days just use a GUI MUA which talks
direct to an ISP SMTP MTA/MSA/relay server, of course.  But that
leaves your base OS unable to send or receive email.  How quaint.  ;-)

> On the broader topic of getting mail through, though, you need
> to use real hostnames when speaking SMTP on the Internet.

  I find that statement misleading at best.

  A bogus reverse-path tends to cause much bigger problems than a
bogus hostname.

  In practical use, you need to have a proper reverse-path, including
a valid domain, for mail to work.  Without it, DSNs (bounces,
receipts) won't make it back to you.  Some types of mail replies may
not work properly, either.  And most important, the majority of active
MXes reject mail if the reverse-path domain does not resolve.

  MTAs operating for Mail Exchange *should* have a proper hostname.
It's very useful for diagnostic purposes.  Received headers are often
used for heuristic spam analysis.  But having a bogus hostname,
especially if all you're doing is relaying through an ISP, is a mostly
minor problem in practice.

> Comcast can't reject all mail with a From: other than comcast.net or doing
> round-trip DNS lookups as they'd break 77.6% of their SOHO users' e-mail.

  Of course.  I never meant to suggest otherwise, and indeed, the fact
that you bring it up makes me think I'm still not explaining things
well.  I'm not saying that mail originated on Comcast's network should
have a reverse-path with a "comcast.net" domain part.  I'm simply
saying it should have a reverse-path which actually leads back to that
mailbox (or a related one).

  That certainly appears to be the case for the original post in this
discussion.  Reverse-path was set to <mod at e521>, when it should have
been <michael.odonnell at comcast.net>.  Simply changing the MTA hostname
to <comcast.net> would have changed the reverse-path to
<mod at comcast.net>.  That might have made the submission go through,
but DSNs would still be mis-routed.

  Aside: In discussions like this, it is important to keep clear the
distinction between envelope (RFC-821, SMTP) and message (RFC-822)
addresses.  So when referring to the RFC-821 stuff, it's best to write
"MAIL FROM" or "reverse-path", since "From:" is conventionally the
RFC-822 header.  (RFC-822 headers are completely irrelevant to SMTP.)

> I'll sometimes also reject mail with bogus Received: headers so using a
> valid hostname is important there too.

  One can certainly do this, but it will block a lot of mail from
Windows MUAs.  I suppose some might consider that a feature.  ;-)  It
will also block mail that originates from inside private corporate
networks.  I routinely see private hops in the "Received:" headers.
Heck, that's how we do things at $DAYJOB.

  I don't like stripping such information, either.  It is often very
useful diagnostically, even if I can't touch the MTAs directly.  (Some
advocate stripping the information to "hide" details of one's internal
mail systems, but I don't see a real security benefit there.)

  Given that Internet email was designed to allow the concept of
gateways to incompatible mail systems, I don't think there's any
requirement that "Received:" be a public Internet node.  I don't find
mention either way in a quick check of RFC-2822.

  Obviously, analysis of "Received:" headers can be useful input to
any spam analysis system, but that's a much more complicated scenario,
and very different from the one under discussion.

> And I do reject bogus HELO's, which drops my spam by about 35%.

  Certainly, but you're operating an incoming MX.  That's a different
scenario than a relay/submission server, with different rules.

> FWIW, my home mail goes over a Comcast connection, but I run my own TLS MTA
> for my MUA's to talk to as we have several reasons not to trust Comcast.

  No argument there.  Computers are hard enough at the best of times,
and Comcast adds apathy, arrogance, incompetence, and greed to the
mix.

-- Ben


More information about the gnhlug-discuss mailing list