From: Andras Galos (galosanetinform.hu)
Date: Wed Feb 13 2008 - 08:40:07 CST

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Victor Duchovni wrote:
> On Wed, Feb 13, 2008 at 02:03:17AM +0100, Andras Galos wrote:
>
>> Then it seems there is no safe way to filter mail on a fake MX after the
>> connection was established, after the RCPT. A fake MX should be fake, no
>> connections at all. I have to say goodbye to those many spam that knock
>> on the wrong door, do I? :(
>
>
> The right way to do "nolisting" is to have a *primary* MX host that
> returns TCP RST for all connections, and then a lower preference
> real MX host.
>
> If you want bogus MX hosts at the end of the MX list, make sure they also
> return RST (not timeout), and don't use greylisting on the primary MX (so
> that connections to the secondary are rare). If you do use greylisting
> whitelist machines that pass rapidly, so that they don't greylisted for
> more than their first few connections.

Yes. Instead of "nolisting" I rather prefer greylisting on the real MX
with lower number, and one (or more) fake MXs with higher numbers. I
just try to receive incoming spam on the fake MX that are addressed to
our own spamtraps for processing. This is what conflicts with the high
number fake MX behavior, since this MX should RST or drop all incoming
SMTP connections instead of greeting, MAIL, RCPT, and 250 in case of
spamtrap mail or 4xx in case of any other mail.

For testing now I setup a "421 MX unavalable" error message to
non-spamtrap mail on this high number fake MX host, and watch any
complains carefully. While greylisting with whitelisting still plays on
the real, primary MX causing legit clients to turn to the fake MX. They
get the whitelisted error on the primary and then the "421 MX
unavalable" error on the fake secondary. I'm curious what if senders
will see the "421 MX unavalable" error in a delay report.
Of course normail whitelisting doesn't generate a delay report on the
client side but some network error, or any other client side error
prevents the mail to be sent and generates a delay report, then one of
the two error messages may appear in the delay report. Or is it
impossible, and no chance at all that this fake error message will be
shown to the sender?

And do you think there are any MTA that still keeps sending the message
after a "554 Unknown user" from the real, primary MX, and the "421 MX
unavalable" from the fake, secondary MX?

Best regards,
Andras Galos

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]