[Maybe OT] - RFC compliance checking at session

Matt Kettler mkettler at evi-inc.com
Fri Feb 29 22:41:29 GMT 2008


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!

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




More information about the MailScanner mailing list