On 23/12/11 01:53, Stan Hoeppner wrote:
> On 12/21/2011 5:30 PM, Peter wrote:
>> There is nothing more frustrating than trying to figure out why your
>> emails are not going through to your customers than when they are
>> accepted for delivery and *not* delivered. I have very little patience
>> for anyone who insists on doing this.
>
> That's because you're confusing discarding spam with discarding legit
> mail.
No.
> Maybe your spam filters or your own special A/S sauce simply suck?
There is no such thing as a 100% accurate SPAM filter.
> The LKML list manager, and many others across the globe, treat 5xx
> rejections of their list mail as bounces, and unsub members after a
> given threshold, 3 IIRC in the case of LKML lists (of which there are
> many dozen, 4 which I sub).
As they should, they risk being flagged as spammers themselves if they
continue to try to deliver to email address that have bounced or rejected.
> I was told I must simply eat the spam along
> with the rest, or not participate. Yes, this is a stupid draconian
> policy, but I must live by their rules, or not participate.
You won't actually be rejecting emails from these (unless your MTA is
mis-configured) because they are all coming from a legitimate sender.
The best you can hope for is to mark them as SPAM based on the content
in which case they should be delivered to a Spam folder (which would not
trigger an unsub).
> Thus, I DISCARD most of the spam from such lists instead of eating it,
> then manually deleting it, or sorting it to a spam folder and then
> deleting it as you apparently do. Why do all the extra work when a
> DISCARD does it for me with zero fuss?
Again, see false positives. They do happen, no matter how good your
filters are.
> This is why I said the world is shades of grey Peter.
Yes, and some emails may look like spam to your filters but actually
aren't. When you take the draconian solution of discarding everything
that looks like spam then you run the risk of missing important emails.
Oh, and as for the RFCs, have a look at RFC 5321:
4.2.5. Reply Codes after DATA and the Subsequent <CRLF>.<CRLF>
When an SMTP server returns a positive completion status (2yz code)
after the DATA command is completed with <CRLF>.<CRLF>, it accepts
responsibility for:
o delivering the message (if the recipient mailbox exists), or
o if attempts to deliver the message fail due to transient
conditions, retrying delivery some reasonable number of times at
intervals as specified in Section 4.5.4.
o if attempts to deliver the message fail due to permanent
conditions, or if repeated attempts to deliver the message fail
due to transient conditions, returning appropriate notification to
the sender of the original message (using the address in the SMTP
MAIL command).
...which one of the above says it can drop email without delivering it?
Peter
