it's possible to have open relays that don't contribute to spam. but
those relays need to employ some other means, e.g. rate limiting, to
Rate limiting is a relatively recent technique. Though very useful it has...
ummm, limited applicability.
mostly because of blacklists. it was working fine for its intended purpose.
One needs to be careful not to dismiss established techniques in favor of the
latest fashionable one that is not as well fully understood.
I don't know what you mean by "relatively recent", but I was doing it at least
as early as April 1999 - that's the last mod date on my source files. RFC 2554
only dates from March 1999.
For example, rate limiting is used to control a single source. It's quite
useful
when used at the destination. At a sufficiently well-run source network, it
also
can be pretty useful.
It's also pretty useful for preventing a relay from being exploited by spammers.
The problem is with zombies. They make mush of old-time models of spam,
since
they demonstrate that a very small data stream from a single source can be
leveraged into a very, very large data stream, given enough sources.
Rate limiting of this type (based on source IP address), if done properly,
doesn't
help or hurt zombies. The rates need to be set such that zombies can send
directly
to the recipients' MXes as easily, and more reliably, as they can send the same
mail via the rate limiting SMTP servers.
One can start imagining more complex rate-limiting models, but then we would
be
talking about research efforts. A BCP is not supposed to rely on research,
especially when it hasn't been done.
Maybe you should stick to talking about things that you know something about.
block spam. the goal of such relays is to make it at least as easy for
the spammer to simply contact the appropriate MXes for the destination
addresses as to use the relays. of course it is necessary for such
relays to record source IP addresses, etc., so that they are as
traceable to their origin as messages sent directly to MXes.
I don't know how much experience you have trying to do such tracing, but the
spamops folks have made quite clear that it is both vastly more effort and
considerably less productive, than one might expect.
That's a problem with mail relaying in general, not just with open relays.
Now if you want to discourage multi-hop mail relaying, that might actually be
useful for lots of reasons besides just traceability.
unfortunately, the vigilante character of various open-relay blacklists
blacklists are not the subject of this BCP.
This thread has pretty much diverged from the subject of your draft
document anyway.
killed any attempt at this kind of innovation. just as we're now in
danger of various kinds of brain-dead "authentication" methods and
meaningless requirements killing useful email functionality.
new authentication methods are not the subject of this BCP.
You mean "your draft document". It's certainly not a BCP as it's
currently written.
Keith
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf