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

From: Gordon Peterson <[email-masked]>
Date: Mon, 22 Jun 2009 13:27:29 -0500

Gordon Peterson wrote:
 > > I believe that ultimately, the best way to deal with spam (okay, we're
 > > talking principle here, not necessarily given existing, insufficiently
 > > clever mail clients) is to simply deliver the spam to the recipient's
 > > system, and let their system decide which mail is wanted, and which is
 > > not, and to either simply delete or archive somewhere the mail which the
 > > recipient user's rules determine is not wanted.  I do not consider a
 > > bounceback message to be necessary or even desirable if a message is
 > > found to be spam/virus/phishing ... in part because you cannot reliably
 > > determine who the original, legitimate sender is (even if there IS one)
 > > to send the bounceback message to.

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

 > Machines do not understand human language. They make spam/ham
decisions based on indeterministic criteria. Why do we run journaled
file system on RAID drives when we would want to kill random files for
the sake of spam abatement?

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.

 > > [...] I (a) still want to use my own
 > > From: address for reply or posting permission purposes, even though (b)
 > > I might not have ANY say at all regarding what outgoing mail server(s)
 > > are used [...]
 > >
 > > The fact that it's easier, or cheaper, or otherwise "more efficient" to
 > > do antispam blocking using some halfassed, braindead scheme which
 > > doesn't work reliably or well for (even some admittedly small)
 > > legitimate mail transmissions doesn't make that the right solution.

 > The difference between content filtering and however braindead
authentication schemes is that the latter ones are deterministic,
rather than easier, or cheaper, or otherwise "more efficient".
Deterministic results mean that messages sent correctly are delivered
independently of their content, uniformly.

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.

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

   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);

   3)  there is an enormous installed base, including applications (as in the 
case of embedded e-mail based accounting systems and similar) which are not 
something where humans are directly involved in sending the messages.

 > you have to accept that your mail will be handled via
compatibility options, including unreliable spam filtering.

That's okay, as long as the unreliable filtering happens at the RECIPIENT (and 
is something they can tweak) and and not at their ISP, (or, worse, enroute) 
where "nothing" can be done about it.

 > If you
expect your From: address to be treated specially, be aware that any
spammer can use it just like you do

That would be true, if they could guess the rules that are being applied to the 
messages.  Since those rules are determined by individual recipients, that 
becomes a very difficult gauntlet for the spammers and abusers to negotiate.

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

 > Anything that is capable to deterministically recognize that you are
really you, is an authentication scheme.

Right, but just establishing the definition seems like it doesn't advance the 
discussion much.

 > > Another situation is where an accounting system at one of my consulting
 > > clients generates and sends electronic invoices, EFT notices, price
 > > updates, etc to their customers.  For these cases, it is VERY helpful
 > > for their own inhouse outgoing LAN mail server (which maybe doesn't try
 > > to handle incoming mail at all) is going to try to send outgoing
 > > mails... if for no other reason than to have a local, inhouse log that
 > > evidences the delivery of the e-mail not just to a relay somewhere, but
 > > actually to (usually) the mail server associated with the destination
 > > indicated for the e-mail message.

 > How come you consider that log line reliable, given that it doesn't
tell you whether the corresponding message has been "simply deleted or
archive somewhere"?

It only tells me what it needs to tell me... that the message was delivered to 
the intended recipient's own incoming mail server (whether inhouse, at their ISP 
or whatever).  Anything that happens to it after that is (of course) beyond our 
control.  At least we got the message "there", and that's adequate evidence of 
our own "best faith" effort to deliver it.  As far as it being reliable, it's as 
reliable as our own outgoing mail server.

 > > Yet another case is where a traveling salesperson connects via a
 > > prospect's WiFi connection during a sales call visit on-site to his
 > > customer, and where that host's corporate network policy blocks sending
 > > of port 25 messages other than to/through that company's own outgoing
 > > SMTP server.

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

 > > I still believe that a far better and more worthwhile direction for spam
 > > blocking involves a combination of tools, probably much of it performed
 > > at the receiving end, involving a finely grained discrimination tailored
 > > to familiar versus unfamiliar (to the recipient) e-mail senders.  This
 > > is not unlike the way locks work... they generally provide a series of
 > > grooves, chamfers and cuts (to the key BLANK!) which prevent the vast
 > > majority of presented keys from even being inserted INTO the lock,
 > > before the pins of the lock do the final determination based on how the
 > > individual key has been cut.

 > Except that you want external unknown people to be able to contact you
by email (otherwise you could just use an unofficial port different
than 25 and relay mail privately within your closed group.)

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

 > It would
be also appreciable if newcomers could open brand new ESP shops and
run their SMTP servers without having to spend years learning the
intricacies of finely grained discrimination tools.

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.

 > As those tools evolve, desperately seeking new ways to find needles in
the growing haystack of spam, users experience more and more
malfunctions. If you dig into the actual rules and data that your
filters base their decisions upon, you may get surprised.

Maybe, but if it's not open to auditing and inspection, then that's the fault of 
the e-mail client software that implements it... and users can presumably switch 
to software that works better.

-- 

Gordon Peterson II
http://personal.terabites.com
1977-2007:  Thirty year anniversary of local area networking

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 23 Jun 2009 07:22:40 +0200

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

>   1)  you can eliminate the shadows and tricks they use to conceal 

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?

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