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

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. 
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 (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.
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, you have to accept that your mail will be handled via 
compatibility options, including unreliable spam filtering. If you 
expect your From: address to be treated specially, be aware that any 
spammer can use it just like you do (and wait until spammers decide to 
relate recipients to the From: addresses that they whitelist.) 
Anything that is capable to deterministically recognize that you are 
really you, is an authentication scheme.
> 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"?
> 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.

> 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.) 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.
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.
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg