OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Re: virtual_alias_maps: rewriting outbound

From: Chris McKeever (techjedigmail.com)
Date: Sun Jul 02 2006 - 15:05:43 CDT


On 7/2/06, Sandy Drobic <postfix-usersjapantest.homelinux.com> wrote:
> Chris McKeever wrote:
> > On 7/2/06, Magnus Bäck <magnusdsek.lth.se> wrote:
> >> On Sunday, July 02, 2006 at 20:35 CEST,
> >> Chris McKeever <techjedigmail.com> wrote:
> >>
> >> > On 7/2/06, Magnus Bäck <magnusdsek.lth.se> wrote:
> >> >
> >> > > But you don't want bounces. Bounces are bad. You want rejections. It
> >> > > is true that virtual alias rewriting is performed recursively -- but
> >> > > the recipient validation made by smtpd(8) is NOT recursive. If a
> >> > > lookup returns a result, the address it valid. This means that your
> >> > > Postfix will accept any address with a dot in it, e.g.
> >> > > blah.blahexample.com, and later bounce the invalid recipient
> >> > > bblahexample.com.
> >
> >>
> >> What server produces this bounce? Without that information the
> >> above bounce message snippet is utterly and completely useless.
> >>
> >> Never show bounce messages. Always show logs from your server.
> >>
> >
> > Magnus - thanks for helping me through this:
> >
> > both messages are coming from the same server, here are the logs - one
> > sent with the 'dot' format and one without - both generate the same
> > unknown user log message
> >
> > Jul 2 14:18:00 prupref-mailgate postfix/virtual[28097]: F0F07C8EBE:
> > to=<nonesemailexample.com>, orig_to=<no.onesemailexample.com>,
> > relay=virtual, delay=3, status=bounced (unknown user:
> > "nonesemailexample.com")
> >
> > Jul 2 14:18:12 prupref-mailgate postfix/virtual[28097]: 7C1A3C8FBD:
> > to=<nonesemailexample.com>, relay=virtual, delay=0, status=bounced
> > (unknown user: "nonesemailexample.com")
>
> If this is one of your servers and example.com is one of the domains that
> your server is hosting, then you will sooner or later be exploited to send
> spam as a backscatter source.
> See the thread "Tarpit "User unknown in local recipient table"?" as an
> example of that.
>
> Restricting the pattern to only match your own domain like Magnus said
> will help a bit, but it is better to use such a virtual alias expansion
> only AFTER you have received the mail with a configuration that only
> allows valid recipients or not at all and use a script or database for
> such address rewriting.
> In any case, you either need access to a database with valid recipient
> addresses or you a flat text file with the list of valid recipients. How
> the textfile is created is up to you and your scripting skills. (^-^)
>
> Sandy
>
>

I must be missing something from A->C. I just read the above mentioned thread.

1) If a user doesnt exist, you want to notify the sender of this - correct??

2) If a spammer sends as someone else to a non-existant user on your
system (barirng IP block or sender verification), you will inevitably
send a message to the spoofed sender based on 1)

3) If the server setup rejects mail that isnt destined for a 'relay'
or local domain, then that stops that component of mail from coming in

4) IF the last piece of the virtual expansion is a LDAP lookup which
only returns valid users, since anything that is performed (aka
rewritten) prior to that will recursively get to the LDAP lookup
doesnt that handle all recipient validation (assuming I understand 1
above correctly)

like I said, maybe I am missing a bridging piece here ..

possibly if someone could show a what the backscatter spam attempt
would do in terms of
email path that would help.

thanks

--
----------------------------------
please respond to the list .. if you need to contact me direct
cgmckeever is the account
prupref.com is the domain

<A href="http://www.prupref.com">Simply Chicago Real Estate</A>