[RFCI-Discuss] plus.net postmaster listing rejected?

[Derek J. Balling]

I re-read your post a half dozen times trying to figure out if you were:

	(a) confused about what the original poster asked,
	(b) creating random hypothetical situations only tangentially  
related to the original poster's topic, or
	(c) just dense.

I opted for (b) in crafting my replies, with only one exception.

On Oct 28, 2006, at 2:59 PM, T wrote:
> While it may be stupid, I don't feel that is a valid reason to list a
> postmaster account.

Neither do we, which is why we didn't list the postmaster account, we  
listed the *abuse* account.

> First, it explains explicitly why the message was rejected

That is *part* of the criteria, but that's not all-inclusive (more on  
this later).

> and a human
> should be able to determine they should just forward the complaint
> along with perhaps only the header of the offending message or worst
> with the date and time and let the stupid postmaster find the message
> himself.
> The sender should do as you do and realize the recipient is stupid and
> a moron (damn, that is me) and forward only the header or specify a
> date and time and sender/recipient.  That is what would be expected if
> it WAS a virus or perhaps if it was a looping 30MB message -- you
> can't be expected to foward either of those so why should you be
> expected to forward any message.

We're not talking about forwarding "any message", we're talking about  
forwarding an example of a phishing spam to the abuse at DOMAIN address,  
which is a perfectly legitimate demand.

> Would you also list the postmaster if it really was a virus and not a
> 419 scam email?

No, because protecting your inbound system from virus infection is  
perfectly rational.
I also wouldn't list "postmaster" for blocking spam, because such a  
rejection, provided it returns a descriptive and specific error  
message, is permitted by our listing policy.

> A mail system should be able to reject messages that are HTML, have
> attachments, are larger than 512 bytes (or 10MB or whatever your limit
> is, 512 bytes might be if it is a really good postmaster that has mail
> forwarded to his phone/mobile device) -- any reason as long as the
> error message is indicative of that reason.  A mail system can reject
> any message it wants (so long as the sender knows how/why and what
> they could should do about it).

Absolutely, a system can reject any message which contains the letter  
"Q" if it wants.

HOWEVER, that doesn't mean that other sites can think that this is  
"reasonable". Mail to postmaster *MUST* be delivered. If you follow  
the letter of the RFCs, even mail with the letter "Q" must be  
accepted to postmaster. Period. Full-stop.

We are a little more sane, in that we allow some exceptions to that  
rule, to help postmasters protect their postmaster mailbox from spam  
load, etc.

> Hmm, suppose, a postmaster has a challenge response filter on their
> mailbox... "reply with X in the subject if you want to reach the
> postmaster".... hmm, that's a question.

"Hoop-Jumping" ... already a listable criteria. You should read the  
listing policy before you wade into these discussions, it'll make you  
seem more on the ball.

> Back to this question, ultimately, you have know you may have to send
> headers only for other messages (real viruses, oversized messages,
> confidential messages) so a postmaster could require that for all
> messages.

Not at all. You can send me headers for a message but that doesn't  
show to me that the user was phishing, it only shows me "you got a  
message from my user". If you want me to act on a user, you're going  
to give me all the necessary evidence, and that includes the body of  
the message. (Viruses, however, are a common exception, since their  
mere presence in a mail reader can be an issue).

But I'm not simply going to take your word for it that the body was  
"bad". Paying customers (even non-paying customers) deserve the  
benefit of the doubt until evidence -- real evidence, not just  
"headers" -- is presented against them.

Cheers,
D


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2419 bytes
Desc: not available
Url : http://lists.megacity.org/pipermail/rfci-discuss/attachments/20061028/fc6b7931/smime.bin