Re: why our server got listed?

Mike Easter <[email protected]> wrote:
> Oleg Bulyzhin wrote:
> 
>> rfc821 (status: standard), 3.6 Relaying:
>> ...
>> If a server-SMTP has accepted the task of relaying the mail and
>> later finds that the forward-path is incorrect or that the mail
>> cannot be delivered for whatever reason, then it must construct an
>> "undeliverable mail" notification message and send it to the
>> originator of the undeliverable mail (as indicated by the
>> reverse-path).
>>
>>
>> rfc2821 (status: proposed standard), 3.7 Relaying:
>> ...
>> If an SMTP server has accepted the task of relaying the mail and
>> later finds that the destination is incorrect or that the mail cannot
>> be delivered for some other reason, then it MUST construct an
>> "undeliverable mail" notification message and send it to the
>> originator of the undeliverable mail (as indicated by the reverse-
>> path).
> 
> rfc means 'request for comments' -- in which rfc 821 was written in 1982
> and superceded by rfc 2821 which was written in 2001 and which also
> failed to adquately address security considerations which were addressed
> in rfc 3552 which required that all rfc/s have security considerations
> addressed.
> 
> rfc 2821 had some security considerations but rfc 3552 recognizes that
> the smtp issues were inadequately addressed.
> 
> RFC 3552 : All RFCs are required to have a Security Considerations
> section.   Historically, such sections have been relatively weak.  This
> document   provides guidelines to RFC authors on how to write a good
> Security Considerations section.
> 
> 6.1. SMTP   When RFC 821 was written, Security Considerations sections
> were not  required in RFCs, and none is contained in that document.
> [RFC 2821]   updated RFC 821 and added a detailed security
> considerations section.   We reproduce here the Security Considerations
> section from that document (with new section numbers).  Our comments are
> indented and prefaced with 'NOTE:'.  We also add a number of new
> sections to cover topics we consider important.
> 
> rfc 3552 has a section: 6.1.1.1. Mail Security and Spoofing
> 
> which starts:  // SMTP mail is inherently insecure in that it is
> feasible for even fairly casual users to negotiate directly with
> receiving and relaying   SMTP servers and create messages that will
> trick a naive recipient into believing that they came from somewhere
> else. //
> 
> Citing a RFC as a basis for a server performing abusively doesn't work
> any better than me citing a RFC which says that some 24 year old RFC
> which was upgraded 5 years ago with some inadquate improvement failed to
> address the inherent insecure aspects of smtp mail handling.
> 
> The realworld situation is that your server is outofdate in its behavior
> if it is newmailing abusive DSNs to bogus Froms and citing the old RFC
> isn't getting you any closer to fixing it.

rfc3552 has status 'best current practice', compare it to 'standard'
for rfc821. Moreover, rfc3552 _does not_ refute rfc821 or 2821. It just
explaining smtp design flaws and describing methods to make it better.

I understand that rfc-like DSNs can be abused. But we have no any newer smtp
standard.

> 
>> Uhm. I didnt ask for delisting or whitelisting.
>> I just want to know why i got listed.
> 
> Presumably abusive backscatter -- if you know you are backscattering or
> newmailing forged Froms, that's all the information you need.  You don't
> need any examples of it.

I do. I need that damn header. I've got reply from spamcop official - 
server was listed cause of spamcop parser failure - trojaned machine of
our client sent mail to spamtrap, but our server got listed instead of that
client.
So we have problem with mail delivery (about 2 days already), diagnostic of it
was unclear, excluding possible reasons yeilds paradoxical result: only
reason (beside an error) why our server may get listed is ...
standard compliance! Funny, isn't it?

> 
>> As i mentioned above i'm talking about DSNs (which i incorrectly
>> named bounce). Supressing DSNs is standard violation. _There are_
>> situations when you should accept mail and deliver it later.
> 
> There are /not/ situations in which you should be manufacturing a
> newmail addressed to some address which never sent you a mail in the
> first place.  Putting yourself into a situation in which you are
> 'holding' a mail which you have accepted insecurely and claiming that it
> is some kind of alleged 'violation' to not abusively newmail a forged
> From is choosing to use some old RFC as an excuse for an unacceptable
> behavior.
> 
> It is a violation of the rights of the mailbox holder of the forged From
> address for you to be emailing unsolicited and abusive mails.  Claiming
> you need to do that to comply with your theory of what an old RFC used
> to mean doesn't justify the abusive server behavior.

It isnt my theory, see rfc 2026 & 3700. 

-- 
Oleg.