And to add my two bits in..
Sorry Rich, but for ISP's on the front line, they often will express..
"... as long as it goes to the spam folder, prefer that to customers
complaining they didnt' get an email ..."
Techies of course might have different 'purist' opinions, but we still
have to live in the real world.
But to your point about 'blocking' during the SMTP process, life would
be so much better if sender's stop obfuscating the MAIL FROM, and make
that clearer for recipient servers to identify the senders. While of
course the message headers can be inspected, the ability to forge those
is much less complicated than forging MAIL FROM.
As a 'user' I would expect to allow '@mailop.org', and not say.. (using
a well known example ... @in.mailop.org) if it is a mailing list.
(Please, no suggestions about work arounds, they are in place of course,
accurate MAIL FROM simply makes life easier for everyone)
Black/White doesn't fit into how most email providers can provide
satisfactory service to their clients, in their eyes.. so handling
'grey' issues needs to involve the decisions of the end user, and only
by 'categorization', eg spam folders can that be accomplished.
On 2019-04-19 8:12 a.m., Rob McEwen wrote:
On 4/19/2019 8:14 AM, Rich Kulawiec wrote:
Best practice is to accept/reject messages only
...
no "spam folders"
Rich,
I generally agree with your entire post - except - for your "no spam
folders" part...
There is the possibility to accept the entire message and then issue the
accept/reject response AFTER the entire message is received (after
"DATA") but still during the original SMTP connection - and THEN put a
copy of the rejected messages into the spam folder. But this does take
more resources. The advantage here is that there is then an "audit
trail" so that the users can have peace of mind if they suspect that the
spam filer blocked a legit message, but they aren't sure if the sender
really sent it - then they can have SOME degree of confidence that it
was never sent when it doesn't show up in either the inbox or the spam
folder.
But due to the extra resource usage of receiving ALL entire messages,
and saving ALL spams to the spam folder - some mail hosters do a
compromise where the very worst spam - particularly spams that are
blacklisted on multiple high-quality sending-IP blacklists - will get
rejected without receiving the messages - then the OTHER spams that are
rejected by content filtering, or whose sending IPs are more mildly
blacklisted - THOSE then go to the spam folder. Many find that to be a
reasonable compromise.
In both cases I described - the filter is STILL giving the FINAL
spam/ham decision at connection time, all fed back to the sender - and
that is SUPERIOR spam filtering. (btw - not only does Microsoft not do
this - Google/Gmail/G-Suite ALSO doesn't do this. There are situations
where Google accepts the message, but then puts it in the spam folder
after additional filtering is done after the original SMTP connection.)
So I do agree that spam filters that provided a reject-accept message at
connection time, as a FINAL filtering decision - are providing a
superior spam filtering service when compared to the ones that accept
the message, but then do after-the-fact filtering, where the sender is
then left with a message SAYING that the message was accepted, but yet
it really wasn't delivered to the inbox.
--
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada
This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.
_______________________________________________
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
