Ian Eiloart wrote:
>
> --On 9 July 2006 20:32:03 -0400 "Bridgit Griffin (Withers)"
> <bridgit@???> wrote:
>
>
>>Hi,
>>
>>Recently, since late Jun, I have been seeing spam that appears to be
>>sent from an email alias I have. However, closer inspection of the spam
>>headers shows that someone connected into the smtp server (Exim ver
>>4.52) then sent it out using my alias.
>>
>>My question is this an exploit or a configuration problem?
>
>
> I think you mean "is this a vulnerability or a configuration problem"? An
> vulnerability is not an exploit, merely an opportunity that could be
> exploited for nefarious means.
>
> In fact, this is a design flaw in the way Internet email works.
Not so much a 'flaw' as a pragmatism.
smtp presumes that authentication of remote user credentials is the
responsibility of the remote host.
> It's quite
> complex, but there are ways of configuring Exim to work within the design
> but minimise the flaw.
Neither complex, nor uncommon to require authenticated
submission. Au contraire - it is the rule, rather than the exception.
A 'challenge', perhaps, for a correspondent MTA to know whether the sending MTA
has performed such auth, yes. But the challenge is not so much in lack of means
as in lack of agreement on a standard that doesn't break easily.
Less difficult to at least determine if the sending MTA is itself in compliance
with registration in DNS, obeys protocols, etc.
Even 'local', on-box shell accounts are presumed to be authenticated via a login
procedure. Further, they can easily be restricted or even disabled entirely.
> For example, it would be possible to configure the
> server such that it will only accept email from your domain when you are
> logged in to the server with a secure password. However, that will produce
> side effects that might not be acceptable to you, which is why it is not
> done by default.
What 'side effects' would any of several conventional authentication methods
produce?
Out-of-the-tarball 'defaults' aside, how many MTA's these days enter production
use without user authentication in place? And how long would it take before any
that do were located, exploited, RBL'ed - and fixed?
>
>
>>My other question is there a way to shut this down? Or can I get enough
>>info to bring to my hosting provider so they can fix whatever problem
>>maybe on their side?
>
>
> You could ask them to require authenticated SMTP for email purporting to be
> from your domains.
A stale donut says they already do so.
Note that the OP specified that she doesn't even *use* conventional email
accounts on these domains anyway.
> However, you'll need to be sure that your MUA is
> configured to support that - and similarly for any other people sending
> email from those domains.
?? tick-the-box on any common / modern one. Even WinWoes.
Not a lot of folk out there who are used to anything else.
> You also need to be aware that this could break
> your membership of some mailing lists (you might not see emails that you've
> sent to the list).
Unlikely. To the extent an MLM includes the poster in its distribution, the
incoming traffic looks like any other valid message.
It may purport to originate from the 'list' address, but even if the OP
<address>@<domain.tld> is listed as 'From:' that is not going to confuse the
MTA, so long as the addressee is a valid local/virtual account.
Ian - I think you are confusing an MTA's behaviour w/r smtp submission from
'peer' mx, with its behaviour towards its own user pool.
Their actions set them apart.
If an MUA were to connect on port 25 and NOT authenticate, any submission not
destined for a valid local/virtual user should be seen as a prohibited relay
attempt.
Nothing 'complex' about the settings to enforce that.
Conversely, any local/virtual user that *has* authenticated is permitted to
submit traffic destined for remote_smtp routing as well as local/virtual delivery.
That is neither complex not uncommon in Exim nor any other 'major' MTA.
IF one needs to support web hosting on a server, AND allow cgi and/or
userland/httpd-land script or interpreted language execution, THEN preventing
these from sending mail can be more of a challenge.
These don't need Exim, port 25, or any other 'reserved' port, so one may have to
use firewall rulesets to block all but port 80, or block all outbound packets
destined FOR remote port 25.
Not an Exim issue in either case.
>
> Furthermore, you need to decide whether you want the Message Headers
> inspected, as well as the envelope (which you can't see here). It's
> entirely possible that the sender address given in the envelope isn't the
> address in the "From:" header.
>
Absent access to the MTA configuration or logs, that's a moot point for the OP.
>
>>Please note I do not have control over the smtp server, my hosting
>>provider does. Also there are no email accounts associated with the
>>domains.
- Which makes hosting provider involvement essential, IF there is actually a
problem.
*snip*
Bill Hacker
