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: Sandy Drobic (postfix-usersjapantest.homelinux.com)
Date: Sun Jul 02 2006 - 15:49:40 CDT


Chris McKeever wrote:
> 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??
>
No, YOU do not notify the recipient. This is the task of the server that
is trying to deliver the mail to your server.
Your task is to first verify, that this message is indeed acceptable and
only accept the message after it has passed this test.
If you don't accept the message, then the server that is trying to send
the mail has the duty to inform the sender that the delivery was not
possible.

Again: This is NOT your task!

That is the difference between accepting a message and bouncing a
message. Once you accept a mail, you are responsible for the mail. If
you reject the mail, the sending server will be responsible.

> 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)
If you accept messages for invalid recipient addresses, yes. That is the
reason why recipient validation is a must for a mailserver.

>
> 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
>
It stopps the entire mail from coming in. Mail is transmitted in several
steps. Only when the last step is acknowledged the mail is transfered to
your server. At the moment, this might not be a problem for your server.
But just imagine a spammer discovers that your setup allows backscatter.
In that case you will be hit with thousands of spam mails within a very
short time. And believe me they will discover this. I see the spam
probes every week on our servers.

> 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.
a mail is transmitted to your gateway:
    sender: joejobinnocent.example.com
    recipient: invalidyou.example.org

Your server accepts the mail, then discovers that the mail can not be
delivered. So it sends the mail as a bounce to the sender address:
    sender: <>
    recipient: joejobinnocent.example.com

That is what you are seeing in the thread I mentioned.

Sandy