(#17827) Properly format SMTP HELO when sending tagmail

[ahpook]

Previously, the tagmail report sending code did not initialize
Net::SMTP.start with a 'helo' option, which causes securely-
configured SMTP servers to reject the mail.

This commit adds settings to control the destination SMTP port
and the value for SMTP HELO, which default to 25 and our fqdn,
respectively.

Report and original patch from Jim Pirzyk.

[slippycheeze]

You mean "incorrectly configured SMTP servers", not securely, and you should probably document why this might be interesting to users in the configuration description. Just having a strictly factual statement of effect, but no meat on why makes this difficult for users to understand.

Part of the reason I emphasise "incorrectly configured" is because some-but-not-all of the SMTP servers that require the HELO / EHLO name to be an FQDN will also reject an unresolvable, or even "no MX exists for", string.

Given that using an internal name, like FQDN on an internal machine, might reject just as much as using the RFC-specified "opaque string for loopback detection" would.

[ahpook]

My experience with HELO checking might be different to yours Daniel -- in Postfix at least, there's a range of helo restrictions varying from the are-you-malware low bar to entry ('must exist', 'must look like a fqdn') to the pretty-clearly-insane ('look up the MX record for the provided hostname and perform some action against it'). So I don't think it's true that all helo restrictions are inherently misconfigurations.

Point taken, and commit added, for adding 'why' to the description though.

[slippycheeze]

I thing you have a tyop in there: "you may to ensure"

[slippycheeze]

My experience with HELO checking might be different to yours Daniel -- in
Postfix at least, there's a range of helo restrictions varying from the
are-you-malware low bar to entry ('must exist', 'must look like a fqdn') to
the pretty-clearly-insane ('look up the MX record for the provided hostname
and perform some action against it'). So I don't think it's true that all
helo restrictions are inherently misconfigurations.

"Looks like FQDN" and "must resolve" are both violations of the spec -
at least, the traditional 821 and 822 pair; they happen to work
because of a coincidence of implementation of most current MTA and
MUAs, but they are definitely not quite right. This has led to
various problems over the years when, eg, a laptop uses the "FQDN" of
"${hostname}", and is rejected by some-but-not-all SMTP servers.

Anyway, yeah, it is a popular, if incorrect, check, and supporting
working around it is a win. :0

[puppetcla]

CLA Signed by ahpook on 2012-08-16 21:00:00 -0700

[adrienthebo]

@ahpook @daniel-pittman I'm dragging this pull request back from the dead to see if we can get a resolution on this. In my uninformed opinion, this seems like a pretty harmless change. Merging this shouldn't break anything, and while it may be working around the deficiencies/configuration of mail servers it's a small change and could make the lives of some users a bit easier. Could we get a definitive yay/nay on this?

Thanks!

[ahpook]

i favor taking it obvs. i interpret daniel's last comment "supporting working around [mail server settings] is a win" as support.

[adrienthebo]

summary: merged into master in 8dbe436; this should be released in 3.3.0. There was a syntax incompatibility with ruby 1.8.7, so I rebased this on master and made the syntax amendment. Thanks for the contribution!