From: mouss (moussnetoyen.net)
Date: Wed Sep 03 2008 - 18:06:50 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

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...).

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]