Raymond Keller wrote:
Ah. I don't have experience with varieties of server installations,
so my guess was very speculative. However, I would be surprised to
hear if there were _no_ implementations wherein MUAs submit to
Postfix via 25 (despite what MUAs ought to do). And I would be
surprised to hear if this hadn't been a more popular method in the
past, perhaps in the era when the underscore allowance was made.
it doesn't matter if they use port 25 (although 587 is recommended to
"separate" the flows so as to make it easier to manage submission and MX
flow with different policies/configs/...). a "normal" MUA doesn't do
mail routing, it sends all mail to a single relay (MSA, Mail Submission
Agent). so if your MTA gets mail from a MUA, then the user is supposed
to be yours (mynetworks, authentication, or whatever mechanism you use
to identify mailers that can relay via your MTA). if it's not your user,
it has no business using your MTA as a relay and it should be rejected.
Whoops, that's wrong, btw. The end-of-line dollar should not be
escaped, sorry.
/^[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+$/ 554 RFC 2821 does not allow bare
address literals.
or
/^(\d\.)+$/ 554 Invalid helo blah blah
(after all, "1.2.3.4.5.6" is invalid as well).
or even
/\d$/ 554 ...
(this will also block things like "mypc3").
Hey, upon further reflection, rejecting unbracketed address literals
as "not FQDN" kind of makes sense. RFC 1123 relaxed the hostname
spec to allow for the first character of hostnames to be numeric but
the author was not worried about this meaning that a hostname would
appear to be a dotted quad "since at least the highest-level
component label will be alphabetic."
So, "1.2.3.4" is not an address literal, it's the
not-fully-qualified hostname "1.2.3.4.com". I don't feel so
disturbed by reject_non_fqdn_helo_hostname's behavior anymore.
some people (including $->self) use:
reject_invalid_helo_hostname
reject_non_fqdn_helo_hostname
Yes, I find those useful, too. (And it was their unexpected
behavior that spawned this thread.)
One can also reject literal IP in helo as it shouldn't be seen in
legitimate mail from MTAs (although it is still theoritically possible).
Meaning reject something like "[a.b.c.d]"? I don't think I know
nearly enough to understand the impact of that. Well, I guess I do
have logs...
search for a thread with subject "Literal IP helo" (Nov 2007).
In my log I see 2883 rejections of mail (for various reasons --
DNSBL, unknown recipient, etc.) from "[a.b.c.d]" hosts out of 12867
total connects. I can't see in the log how many "[a.b.c.d]"s were
_delivered_, however. :( I suppose I can enable this restriction
with a warn_if_reject as you suggested earlier, and start to gather
stats.
yes. If I have the time, I'll parse my delivered mail to get some stats.
or if that's too aggressive:
/^\[/ reject_unknown_client
That's interesting. What does reject_unknown_client do in cases of
unspecified hostname (which I take address literals to be)? The
code seems to suggest that anything but a success is counted as a
failure and is 450'd. I might prefer an outright rejection to
possibly days of delay before a DSN shows up for the sender.
all the transactions I see with a literal IP (from an unknown client)
are junk. so there is no problem in sending a 4xx (the ratware doesn't
care anyway. some will retry, some will pass their way).
that said, a simple reject is probably ok (I actually used a a "plain"
reject for some time. I may switch back...).
