On Fri, May 8, 2009 at 6:34 PM, Trey Briggs <tbri...@api-digital.com> wrote:
> On Fri, May 8, 2009 at 7:07 PM, Curtis <postfixu...@isparks.com> wrote:
>> On Fri, May 8, 2009 at 5:22 PM, Wietse Venema <wie...@porcupine.org> wrote:
>>>
>>> Curtis:
>>> > I'm building a spam filtering appliance using Postfix.  We will be
>>> > making
>>> > every effort to reject invalid recipient addresses at SMTP time, but
>>> > since
>>> > we will not always be made aware when an email box on a final
>>> > destination
>>> > server is no longer valid, we'd like to disable all bouncing after SMTP
>>> > time.
>>> > I saw one person suggest disabling the bounce service in
>>> > /etc/master.cf...which does disable bouncing, but the logs now show
>>> > the following error:
>>> >  "status=deferred (bounce or trace service failure)"
>>> >
>>> > What is the correct way to disable bounces?
>>>
>>> None. You need to keep the valid recipient list up-to-date.  Postfix
>>> does not (and will not, over my dead body) do what you ask for.
>>>
>>>        Wietse
>>
>> We have every intention of keeping our valid recipient lists up-to-date,
>> because we want to reject all email sent to invalid recipients at smtp time.
>>   However, since we don't control the remote servers that we filter email
>> for and because we'll be managing thousands of domains and tens of thousands
>> of email addresses, it's possible, that from time to time, that we'll not be
>> made aware of recipients that are no longer valid.  In those cases, if we
>> bounce after smtp, postfix is going to start spewing backscatter.  I guess
>> the good news is that since we're filtering out most spam, that
>> the likelihood of backscatter is greatly reduced, but I was hoping for total
>> elimination.
>>
>> What I'd prefer to do here is have the bounces held for customer review so
>> that they can realize that they've got an email address that isn't
>> delivering and fix the problem on their end.
>> Curtis
>>
>
> I'm doing something similar to what you are looking for. You can set
> unverified_sender_reject_code = 550 and
> unverified_recipient_reject_reason = Custom Message
>
> Then set up something like syslog-ng to grep out 'Custom Message' from
> your maillog in realtime and send those lines to a named pipe (man
> mkfifo). Then create a daemon (I used perl) to read from that pipe,
> grep out the invalidr...@domain.tld and perform any action you want
> beyond that (for example email the IT guy at domain.tld).
>
> Here's an example daemon and syslog-ng config:
>
> daemon:
> #!/usr/local/bin/perl
> sysopen(FIFO, '/usr/local/bin/invldrcptpipe', O_RDONLY) or die "Can't
> open pipe\n";
>        while(my $log_entry = <FIFO>)
>
>        {
>          $log_entry =~ /\[(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})\]/;
>          $ip = $1;
>        }
> close(FIFO);
> # I am grabbing IP instead of email address
>
> syslog-ng:
> destination d_pipe { pipe("/usr/local/bin/invldrcptpipe"); };
> filter f_user_unk {
>                   program("postfix\/smtp") and
>                   match("User unknown"); };
> log { source(src); filter(f_mail); filter(f_info); filter(f_user_unk);
> destination(d_pipe); };
>
>
> It seems pretty quick (this server can still handle 5mil messages a
> day with lots of spam scans), mine actually counts IP address hits in
> a DB and postfix will block if the count is higher than 20 in 10
> minutes (a cleanup script handles the expiration). Seems to help curb
> dictionary attacks.
>
> --
> Trey Briggs
> Advanced Systems Engineer
> API Digital
> tbri...@apid.com
> 256-508-2368
>

Interesting.  You just made me realize that the solution is really
pretty simple... we can parse the logs for bounces, and just
automatically shut off those addresses.  (And send an automated email
to the domain administrator once per day of addresses that have been
automatically shut down.)  Certainly a lot simpler said that done, but
doable.

Thanks,

Curtis

Reply via email to