Re: why our server got listed?

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.

> 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.

> 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.

-- 
Mike Easter
kibitzer, not SC admin