[Maybe OT] - RFC compliance checking at session
glenn.steen at gmail.com
Fri Feb 29 23:42:47 GMT 2008
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.
email: glenn < dot > steen < at > gmail < dot > com
work: glenn < dot > steen < at > ap1 < dot > se
More information about the MailScanner