Phil Vandry wrote:
On Tue, Jul 01, 2008 at 11:54:46AM +0200, Jeroen Massar wrote:
The magic keyword: REJECT-ON-SMTP-DATA.
[snip description on how to reject during DATA phase]
Unfortunately there is also a side-effect, partially, one has to have
all inbound servers use this trick, and it
I think the problem that was being raised here was that past the DATA phase, if
one recipient is going to receive the message and another is going to reject
it, you have lost the ability to communicate this back to the sender (at least
without an NDR). Thus the problem of mails disappearing
one note about whether to filter at receiving SMTP server or later.
The receiving SMTP server is the one that has the conversation with the
sender.
Rejecting mail from servers having an un-backtranslatable IP is best
done right away by the receiving server right after the HELO command by
issuing
Ross Vandegrift wrote:
On Thu, Jul 03, 2008 at 10:36:27PM -0400, Christian Koch wrote:
i definitely see value in appliances like the fcp and route science box, i
just think for a smaller provider it may not be necessary - or maybe i have
it backwards,and it is a better solution for a smaller
Jean-François Mezei wrote:
Blocking messages as early as possible also greatly reduces the load on
your system, disk storage requirements etc.
Rejecting during the SMTP dialog but before you signal that you've
accepted the DATA output also also pushes the responsibility for sending
a DSN to
Nick:
Leaving a domain and IP fallow for such a long time will end up looking like
my garden did this year when I did the same thing -- overrun with weeds.
Sending a blanket e-mail to NANOG is not going to get the attention of those
who manage the e-mail flow (unless you domain belonged to a
Just like I should have with my garden, rather than replant among the weed
seeds and spend 99% of my time pulling weeds, I would recommend sowing a new
field by moving your outbound e-mail server(s) to some fresh address space
(different /24 to be sure, ideally another section of SWIPed space)
[EMAIL PROTECTED] (Randy Bush) writes:
if the ipv4 free pool run-out produces a lot of address shifting and
recycling of old address space, will there be a market in clean-up
services such as the above. give them your newly-acquired address space
for two months before you need to use it, and
The real solution to the scorched earth problem is for aging from
blacklists to be dynamic.
If a given IP hasn't spammed or otherwise been naughty in some period of
time, and the RP contact information for that netblock exists and
responds, then the benefit of the doubt should go to the neblock
The real solution to the scorched earth problem is for aging from
blacklists to be dynamic.
Um, this isn't exactly a revolutionary idea. Almost without
exception* the blacklists that are widely used have some sort of
age-out so that the remove addresses that don't continue to show bad
behavior.
[EMAIL PROTECTED] writes:
Apart from using Bernstein's tinydns, anyone have any scripts
for looking for problems in zone files or for incrementing the
serial number reliably?
If you are using BIND, your problem is solved by DDNS and nsupdate.
this has the added advantage of making it
Quoting [EMAIL PROTECTED]:
Apart from using Bernstein's tinydns, anyone have any scripts
for looking for problems in zone files or for incrementing the
serial number reliably?
Check out BIND's named-checkzone and named-compilezone, depending on
exactly what you are looking for. There are a
12 matches
Mail list logo
