Fwd: Re: [Asrg] Precedence headers and spam

[Yakov Shafranovich <[e-mail]>]

>From: Vernon Schryver <[e-mail]>
> > ...
> > 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 / <[e-mail]>
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
[e-mail]
https://www1.ietf.org/mailman/listinfo/asrg