Re: [Asrg] What are the IPs that sends mail for a domain?

Gordon Peterson wrote:
>  > Except that you cannot reliably determine whether a message is spam.
>
> UCE isn't the only issue.  The issue is whether it's something that the 
> recipient wants to receive, or doesn't want to see.
What if I don't like to see bad news?

>  > Machines do not understand human language. [...]
>
> I wouldn't "kill" stuff, unless the user has specified rules under which 
> they are willing to summarily kill it.  I think it's generally 
> worthwhile to file stuff on a local hard drive at the recipient, hard 
> drive space is cheap, so that they can go back and search for something 
> that maybe got routed to the spam folder that shouldn't have been.
Are senders required to send an SMS to prompt recipients to go 
search for their mail? Why don't we just use SMS transport then? We 
can still store it on our hard disks via bluetooth connections...
> Deterministically bad or incorrect is not an improvement.  The finely 
> grained rules I am talking about are absolutely deterministic, in any 
> case... even if they are hard for spammers to determine.
They are not. You may hold they are deterministic since they are the 
output of a deterministic machine. However, from users' points of 
view, both senders and recipients, based on just the data that each 
one sees, the behavior is randomly intermittent.
In facts, spammers and friends are treated alike. Making friend or 
foe determinations based on authentication would allow to discern 
more consistently.
>  > IMHO, the correct way to go is to have a (weak) authentication scheme
> that works well enough for most relevant cases, and at the same time
> keep the existing system as a compatibility option for the cases where
> it doesn't work.
>
>  > If you want to use prehistoric appliances deploying obsolete mail
> transmission methods that have historically proven to be vulnerable to
> spammers,
>
> All mail can be vulnerable to spammers.  But:
>
>   1)  you can eliminate the shadows and tricks they use to conceal 
> themselves;
Not quite. E.g., Bill recently suggested, and I agree, that the 
single most effective method is using Spamhaus Zen list. Why would 
people use it if they could eliminate shadows and tricks spammers use?
>   2)  you can set up rules to eliminate the great majority of bogus 
> stuff (and I continue to add rules to my personal copy of Thunderbird on 
> an ongoing basis);
One could generate all combination of words and then look for those 
that make sense. That collection would include most literature 
masterpieces. It is not deemed the most effective method for 
creating new ones, though. BTW, how would your rules behave at that?
>  > (and wait until spammers decide to
> relate recipients to the From: addresses that they whitelist.)
>
> They have no way to determine what addresses are and are not 
> whitelisted, and what the rules are for a given recipient.
There are places where they can sniff mail traffic. Infected 
machines is one, but I guess there are more, possibly related with 
spyware (too many times sending a sporadic mail abroad starts a 
sequence of spam apparently unrelated, except for the language; and 
I don't believe all of those recipients were infected, as some were 
part of tough organizations.) They could easily try and pick your 
whitelisted addresses from the recipients you write to, for example. 
I think they don't do it because they don't need it, yet.
>  > Try port 587.
>
> How about if he's sitting at a desktop machine inside the customer's 
> office? He's not going to be able to reconfigure the mail software he's 
> sitting in front of.
Webmail

> Fine.  I am willing to simply decree that (for example) I don't accept 
> HTML mail, big messages, or attachments from people I don't know.  This 
> doesn't preclude people from contacting me, only preventing them from 
> abusing me (by whatever my own definition of "abuse" is, and ONLY MY 
> DEFINITION MATTERS!).
There are legitimate senders who use HTML just because it may look 
nicer, and is very difficult to acquaint them with the technical 
details that make it bad. Given that, you can delete their messages 
without telling, or reject them with an appropriate message. For a 
number of reasons, complicated rules are fired after the message has 
been accepted, and they may result in deleting or hiding the 
message. The more often that happens, the more misunderstandings. 
You may call that anything but a reliable system.
> I think the place to implement these tools is at the e-mail client 
> software level, where it is integrated and maps well with the user 
> interface that the user is familiar to with their e-mail.
Hmm... and the desktop machine inside the customer's office?

_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg