RE: [Exim] how to accept a recipient address format that nor…

Página Inicial
Delete this message
Reply to this message
Autor: Ralf Hauser
Data:  
Para: exim-users
Assunto: RE: [Exim] how to accept a recipient address format that normal smtp servers reject before accepting the body/attachments

> -----Original Message-----
> From: Robert Kehl [mailto:mailinglists@robertkehl.de]

...
> > I was hoping to be able to configure my exim such that it will accept
> > one
> > type of addresses that most others don't to avoid inadvertent sending
> > over a
> > non-TLS-protected connection.
>
> Ack. But how is to be using your server, assumingly your users? These
> users shouldn't be allowed to send their mail with a *very* special
> local part over any other SMTP?

need not be a local part, can be the domain.
>
> Again, no way. They may use *any* SMTP Relay server - be it an illegal
> one or are legal they probably pay for or whatever.
>
> If you force their SMTP accounts on their local PCs to include a
> non-existent domain, which won't be routed over the internet but only
> accepted by your exim server, you put yourself on the line. I could go
> and grab your "placeHolderForNoDomain.com", and all of your user will
> send their mail to my legitimate mail server accepting every single
> mail.

Sure, I own the domain, just no MX record is set for it in DNS.
Or preferably, I would use
bogusSmtpHost.MyRealDomain.tld
>
> In short: You cannot ensure that a non-existent domain stays a
> non-existent domain - think of the latest Verisign thing. Do not use the
> reserved domains like example.com either, they are not intended for
> this.

Agreed.
>
> If you want to construct a secure network with roaming agents outside in
> the world, secure their workstations, train your personnel, train your
> users, trim their Mail clients. You have to have control over the
> workstations to be passably sure your mail traffic is never sent over
> any unwanted server or unencrypted connection.

sounds like a very "soft" approach
>
> > > Your dummy domain would for sure never succeed when anyone uses a
> > > different SMTP server than yours, as the dummy domain probably won't
> > > resolve in real DNS.
> > Sounds like a good idea. Hope the other smtps domains really do reject
> > that
> > dummy domain BEFORE "sucking" the body and attachment over the
> > typically unprotected wire.
>
> Bad idea! Any Relay server will first accept the message and *later*
> reject it, leaving traces in its' various log files, I presume.

if so, I guess my idea won't work ... :(
> > #1)
> > recipient_unqualified_hosts = *
> > #2)
> > qualify_recipient = placeHolderForNoDomain.com
> >
> > begin acl
> >
> > acl_check_rcpt:
> > #3)
> >   accept  hosts = :
> >   deny    local_parts   = ^.*[@%!/|] : ^\\.

> >
> > #4)
> > accept authenticated = *
> > >>
> > Right, doesn't my above exim.conf say
> > 1) anybody can provide unqualified recipients
>
> Yes.
>
> > 2) if an unqualified recipient is found, add
> "placeHolderForNoDomain.com"
>
> Yes.
>
> > 3) anybody can send me a mail as long as local_parts condition is
> fulfilled
>
> Well... anybody with a local part NOT containing some unwanted symbols
> is actually denied.

isn't it exactly the opposite: "anybody with a local part containing some
unwanted symbols is actually denied"?
> > 4) furthermore, each sender needs to SMTP-AUTH?
>
> Well... #4) says every successfully authenticated sender will be
> ACCEPTed - that's quite a difference from "anyone MUST authenticate".

Sure, a different sequence in time, but will the result be different too?
>
> > If that is right, I don't understand, why I get "5.1.2. Bad Recipient
> > format --- no domain specified..."
>
> Me not either... sorry. Perhaps it's a message from your Client?!?

Mozilla Messenger's error notifications to the end-user could certainly be
made more unique/manageable.
> I can
> imagine there's hardly an email client that's allowing the user to omit
> the domain part. At least the usual suspects will always "assist" the
> user, I presume. Haven't had a closer look, though.

you may well be right unfortunately...

Conclusion:
if bogusSmtpHost.MyRealDomain.tld would at least stop users from
inadvertently send to non-relay smtps, this would still be good collateral
to the soft measures you mention?