[PLUG] Comcast Bouncing Outbound Mail

[Paul Johnson]

Stop me if I misinterpreted what you're saying...

Rich Shepard <rshepard at appl-ecosys.com> writes:

>   I am slowly modifying my postfix UCE rules to discard rather than reject.

So you're breaking the standards to break reliable mail delivery and
*not* save any bandwidth?  How does that help?

The difference between dropping (ie, sending an affirmative SMTP
response and then routing to /dev/null) and rejecting (sending a
negative SMTP response) is that one is the right way to do it, and the
other is the badly broken way to do it and both use the same amount of
bandwidth.

Don't just silently drop messages on the floor, either accept them or
reject them or you run a very real risk of losing legitimate mail that
matched the spam filter.  Your correspondents will get angry since
they'll think you're deliberately ignoring them since your MTA's
accepting and dropping it instead of flat out rejecting it like it
should.  I'm astounded that rfc-ignorant.org doesn't yet have a catagory
for this kind of brokenness...I know I wouldn't even bother trying to
send mail to a server that I can't rely on to either properly deliver a
message or tell me that it didn't make it.

> When I discovered that I could route the junk to /dev/nul I started using
> that option. I save the bandwidth of the rejection message and most of those
> go to either spoofed addresses or to providers who don't seem to care.

Except you're not saving any bandwidth doing it that way, and you're
potentially sacrificing the reliability of your server for legit senders
to do it.

I strongly suggest you learn a bit more about SMTP before you start
trying to play with how your MTA slings mail around.

-- 
Paul Johnson
<baloo at ursine.ca>
Linux.  You can find a worse OS, but it costs more.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
URL: <http://lists.pdxlinux.org/pipermail/plug/attachments/20040612/a56fd5a7/attachment.asc>