From: Vernon Schryver <vjs@calcite.rhyolite.com>My suggestion is for each MTA to adjust the header accordingly according to either formal guidelines or a local policy. For example, if a MTA receives a message from a trusted party (in a RMX/rDNS scheme) then it will trust the header set by that party, otherwise it will adjust it. Also, a side benefit of this, would be providing a standard way for all anti-spam software and filters to mark something as spam in a standard way.
> ...
> as part of an overall solution. If we utilize some form of a RMX/rDNS
> system, there is still an issue of dealing with the email arriving from
> ...
> either here or elsewhere on the Net: assigning priority to each message.
> Messages with different priority levels can be routed accordingly, possible
> spam can be delayed by a significant number of hours or days during which
> the spammer's website and email accounts will be probably terminated by
> their ISP. Legitimate email will still get through, but the inherent
> "slowness" will force the senders to complain to their ISP to switch over
> to a RMX or rDNS system.
>
> There are already two headers mentioned in RFC 2076, section 3.9:
> "Priority:" and "Precedence:" According to RFC 2076 these headers "can
> ...
I don't understand the idea It can't be that spam either would or
would not have a Priority or Precedence header as it comes from the
spammer, since spammers would immediately add or not the required
header. Do you mean that a receiving MTA would add or adjust a header
based on RMX or reverse DNS checking, and then delay or expedite the
message based the value in the header?
As I mentioned an additional benefit would be provided by standard header that it can be used by filters and anti-spam software to mark messages as spam. This way the MTA or the local agent that is delivering the mail does not have to define a custom interface to the anti-spam software.Problems I see with that idea are: - There's no need for the receiving MTA to add headers. It could must segregate incoming messages, such as into sendmail queue directories. You could delay the processing of some queues.
That is very possible, I would have to think about this point some more. However, if enough complaints received to a local ISP, wouldn't that force the ISP in turn to complain to the remote ISP, thus speeding up adoption of RMX/rDNS?- There will be at least as many complaints from local users about the delays than from remote users to the remote users' ISPs.
The intent is two fold: stop fly-by-night operations NOW by delaying their mail and in the future if any kind of authentication scheme or rDNS/RMX scheme is implemented, to speed up transition. And a side benefit of standardized spam headers.- What do you do with spam after it has been delayed, deliver it? Or is the idea only to delay and penalize any and all mail with RMX/rDNS support by sending MTAs to speed up the transition to common support for RMX/rDNS?
These bulk senders are known and can be dealt with accordingly much like AOL suing CyberPromotions. My intent is to stop "fly-by-night" operations that use Nigerian scams, fake address, spoofing, domains names without whois information, etc. These kind of fly-by-night operations are usually shut down fast and move on elsewhere. If their mail is delayed that can severely cut into their profits and reduce the incentive to send spam.- If you accept the mail and then delay it, it doesn't matter whether the spammers accounts have been terminated as far as spam victim is concerned. It's also a stretch to say that the spammer's accounts would be terminated within hours or even days. Many spammers have what they call "bulllet proof bandwidth." Then there are the senders of unsolicited bulk advertising including Topica, Roving Software, RealNetworks, American Express, and most DMA members (according to the DMA if not most DMA members themselves). There is no prospect of the accounts of those organizations being terminated.