On Thu, 2006-01-05 at 11:44 +0000, Clive McDowell wrote:
> Are there any circumstances under which such messages should be
> allowed through or can I simply refuse messages with blank from
> headers?
You should probably post the log line for that message, however it looks
like your hub is seriously misconfigured - and acting as an open or at
least semi-open relay, so ORBS appear to be quite correct here.
However what you have posted concerns me as I think you have got hold of
the wrong end of the stick here - forgive me if I now go on to tell you
things you already know...
Firstly mail routing in general has absolutely *nothing* to do with
message headers. You may apply additional policy which does do
restrictions based on headers, but really this should have been rejected
way before the headers were received. So the From: header being empty
is a misleading symptom in this case.
The SMTP session to your box would have looked like this (stuff ORBS
sent is prefixed with >>>, replies with <<<, the numbers are there to
make it easier for me to refer to):-
1. <<< 220 some response info
2. >>> HELO ordb.org
3. <<< 250 my-name Hello ordb.org [217.157.38.18]
4. >>> MAIL FROM: <>
5. <<< 250 OK
6. >>> RCPT TO: <marvin@???>
Line 4, giving an empty sender address, shows that this is a bounce
message - this is perfectly legal and do not allow any idiots to tell
you otherwise. You may wish to have different rules in your ACLs for
null senders - for example exim.org does not allow null senders to send
to the mailing list addresses because messages are *never* sent with
sender addresses of the mailing list, and so bounces can never be
returned to them (unless the one doing the bouncing is badly broken - in
which case it is their problem, not mine).
Your real problem is at line 6 where an address which is not on your
site was specified, and you accepted it. On most systems line 7 should
have been a "550 relay not permitted", but since the message went
through you must have accepted it.
So you must not be doing any checks for this in the ACL that handles
RCPT. This will be down to one of these:-
1. You are accepting without doing any checking at all (ie a full
open relay).
2. You are accepting if the sender address is null without checking
that the recipient is in a domain that you handle.
3. You are checking the sender against a list of
networks/authenticated users/domain and have miscoded the check
so that it is too wide (ie network 0.0.0.0/0, or mishandles
(say) the authenticated user being not set).
Without seeing your configuration we can't say more than that. I
suggest you look at your config and see if there is a problem in the
RCPT ACL. If you cannot see a problem then post it here and someone
will look through it for you.
There are open relay testing services that you can use against your own
servers. Doing this occasionally is well worth it in terms of
preventative maintenance.
Nigel.
--
[ Nigel Metheringham Nigel.Metheringham@??? ]
[ - Comments in this message are my own and not ITO opinion/policy - ]
