On Mon, Sep 17, 2001 at 04:47:22PM -0400, Greg A. Woods wrote:
> [ On Monday, September 17, 2001 at 16:27:51 (-0400), Dave C. wrote: ]
> > Actually, if he's doing this in a filter, that really doesnt apply,
> > becuase exim will have already accepted the message.
True.
> Nothing in RFC 1123 section 5.2.5 applies w.r.t. any local security
> policy decision.
Security is the wrong word, but knowing what you are supposed to and not
supposed to do is kind of helpful.
> > If he wants to sort or /dev/null the message after its been recieved if
> > the helo doesnt match the rDNS, thats entirely up to him.
Well, that's certainly bloody stupid, whatever happened to reliable mail
delivery? Why bother using SMTP if you're just going to /dev/null the mail?
> It's actually a lot better to refuse the connection instantly instead of
> receiving a message and then later dropping the message in the bit bucket.
Not quite:
a) you don't know at the time they connect what their helo line is going
to be.
b) the only kind of error response you can give to a legitimately formatted
helo line is a 421, in which case dropping the connection is legitimate.
If you meant just dropping the connection straight, that's a very silly
thing to do, and helps noone.
Your alternative is to 550 at the RCPT TO:<...> stage (or the MAIL
FROM:<...>)
> At least then a legitimate sender can be informed of a configuration
> problem at their end and hopefully get it fixed.
Like that'll happen.
I run something called SAUCE on my outward facing MX for colondot.net,
this does basically that kind of thing. I end up having to put in exceptions
for people I trust with broken mail systems, rather than managing to
persuade people to fix them.
MBM
--
Matthew Byng-Maddick <mbm@???> http://colondot.net/
