[Maybe OT] - RFC compliance checking at session

[Glenn Steen]

On 29/02/2008, Matt Kettler <mkettler at evi-inc.com> wrote:
> Glenn Steen wrote:
>  > On 29/02/2008, Matt Kettler <mkettler at evi-inc.com> wrote:
>  >> Hostmaster wrote:
>  >>  > Hi All,
>  >>  >
>  >>  > I would like to illicit some opinions from you other MailScanner using
>  >>  > MX-administrators.
>  >>
>  >>
>  >> Pretty much all your opinions here are valid, except:
>  >>
>  >>
>  >>   > and the IP does not accept return SMTP – indicating that
>  >>  > it's probably a web server and not an MTA itself.
>  >>
>  >>
>  >> I find that conclusion irrational. Why wouldn't it be an MTA?
>  >>
>  >>  Anyone large enough to have separate MX (inbound) and smarthost (outbound)
>  >>  servers should *NOT* be accepting inbound SMTP connections to their smarthost
>  >>  servers from the outside world. Only their internal network should be able to
>  >>  SMTP to the smarthost.
>  >>
>  >>  There's no reason to allow it, so best practice would suggest you should close
>  >>  that off at the firewall. Any legitimate mail delivery attempts will go to the
>  >>  MX servers. Therefore any attempts to connect to port 25 on the SmartHost from
>  >>  the outside are either hackers, scans, or random pokes and prods at parts of
>  >>  your network nobody on the outside belongs in.
>  >>
>  >>
>  >>  I think it's a pretty far jump to assume that any system that generates SMTP but
>  >>  doesn't accept inbound from you can't be an MTA. It's quite possible it is an
>  >>  MTA, but you're not authorized to try to queue mail there and are firewalled out.
>  >>
>  > I'm not going to disagree (much:-) with you today/tonight Matt (not
>  > sober enough, and I need be very sharp when doing that:-):-), but what
>  > about all that stuff ... domain litterals etc... all there to
>  > facilitate bouncing when there is no DNS etc. Kind of implies that all
>  > SMTP sendersare supposed to be able to be receivers too, now don't it?
>  > Or maybe I'm in delirium tremens and that is just a figment of that state:-):-)
>
>
> Follow up again later.. I can't make much sense of what you're saying right now.
>
>  Domain literals exist to handle sending messages when DNS is down. But I don't
>  see anywhere that suggests using them for bounces.
>
>  As best I can tell it's a flagrant violation of many RFCs to send a bounce (or
>  any other DSN) to anything other than the return path.
>
>  Trying to create a domain literal using the IP address of the host that
>  delivered the email strikes me as absurdly broken. If nothing else, doing this
>  would require that all SMTP clients also be mailservers... Ouch!
Yeah... It must be the booze. Sorry:-).
I'm certain I've seen something like that though (in a DISCUSSION
clause, but ... well, the memory isn't good when sober... So ....:-).

>  Relevant RFC's describing that delivery failure notifications be sent to the
>  reverse path in the MAIL FROM: command:
>
>  RFC 821 section 3.6 (MUST)
>  RFC 2821 section 3.7 (MUST)
>  RFC 1123 section 5.3.3 (specifies SHOULD be the envelope return, not must)
>  RFC 3461 section 6.1 (simply described as fact, with no MUST or SHOULD.)
>
Probably me getting confused with one of those. Thanks for taking the time Matt.

Cheers
-- 
-- Glenn
email: glenn < dot > steen < at > gmail < dot > com
work: glenn < dot > steen < at > ap1 < dot > se