ietf-asrg
[Top] [All Lists]

Fwd: Re: [Asrg] Precedence headers and spam

2003-05-07 08:51:00

From: Vernon Schryver <vjs(_at_)calcite(_dot_)rhyolite(_dot_)com>
> ...
> 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?

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.

  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.

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.

  - There will be at least as many complaints from local users about
   the delays than from remote users to the remote users' ISPs.

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?

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

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.

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

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.

Sincerely,
Yakov

---------------------------------------------------------------------------------------------------
Yakov Shafranovich / <research(_at_)solidmatrix(_dot_)com>
SolidMatrix Research, a division of SolidMatrix Technologies, Inc.
---------------------------------------------------------------------------------------------------
"One who watches the wind will never sow, and one who keeps his eyes on
the clouds will never reap" (Ecclesiastes 11:4)
---------------------------------------------------------------------------------------------------
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg



<Prev in Thread] Current Thread [Next in Thread>