Mailing List Archive

1 2  View All
Re: Google & STARTTLS [ In reply to ]
Am 26. August 2022 17:32:05 MESZ schrieb "John R. Levine" <johnl@iecc.com>:
>On Fri, 26 Aug 2022, Michael Brunnbauer wrote:
>> Hello John,
>>
>> silent dropping of E-Mail is a criminal offense in Germany and should
>be
>> everywhere else.
>
>I would be most interested to see a citation to the law (in German is
>fine) and court cases where spammers have forced mail systems to
>deliver
>their mail. Because I have spent a lot of time looking at laws all
>over
>the world that apply to e-mail, and I don't believe it.
>
>Regards,
>John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for
>Dummies",
>Please consider the environment before reading this e-mail.
>https://jl.ly

Hi,

it is the silent part that is not allowed.

As long as you reject the mail before delivery everything is fine.

If you close the SMTP dialogue with 250 OK you have to deliver the mail to its recipient. And the recipient has to read it, at least in a business setting.

--
Robert
Re: Google & STARTTLS [ In reply to ]
Thus said Robert Sander on Fri, 26 Aug 2022 16:01:49 +0200:

> Do not filter mails without telling anyone. And if you do not reject
> suspicious emails but deliver them into a SPAM folder the recipient is
> responsible to check it very regularily.

I think we have to be careful telling people what their mail service can
and cannot "legally" do with respect to filtering.

What about RBLs? I find them quite useful and account for blocking a
large amount of junk email. What about pre-acceptance checks like
greeting delays or DNS checks, or even protocol violations, all of which
may reject a message. There is no guarantee that the message will get
properly routed back to the sender.

While I agree that it is certainly a benefit to filter messages into
junk folder destinations, I also think that service providers filtering
emails or even rejecting suspicious emails given the preferences of
their users is their prerogative. If the customer doesn't like it they
can find a new service. Clearly the best filtering mechanism is one that
is tailored tightly to the user or customer preferences.

This is the problem with big one size fits all providers like Gmail; as
they tend to accept otherwise unacceptable practices in an effort or
zeal to block junk email. Instead of devising better tools, they just
become a morass.

Andy
Re: Google & STARTTLS [ In reply to ]
Thus said George Georgalis on Fri, 26 Aug 2022 07:15:20 -0700:

> I switched my MX to Google when maintaining spam filters became too
> time consuming... I would like to unplug from Google now, but I am
> afraid of the consequences.

That's interesting. I haven't dedicated much time to spam filters
lately, and I have less spam than I ever did when I used Gmail addresses
that I had never given out to anyone.

I rely mostly upon RBLs at this point, but I do still see a lot of email
that is "blocked" due to greeting delay and protocol violations.

Andy
Re: Google & STARTTLS [ In reply to ]
Hi Andy,

Looking at my prequeue script (for QMAILQUEUE), it included
- maintaining my own cbd to rbl messages that failed the
sbl-xbl.spamhaus.org rbl check
- clamdscan
- bypassed dnsbl.sorbs.net because major isp got in the list
- bypassed bl.spamcop.net because yahoo groups got in the list
- spamc (Apache SpamAssassin)

IIRC the time consuming part was clamdscan, because although it was
efficient and accurate at mail processing, and my db was refreshed
continuously, the software required recompiling, testing and reinstalling
every 3 weeks or so due to emerging threats, this was around 2008.

I used a script to convert registrar country codes (bad actors) to ip for
rbl processing by ipsvd (big win) and I expect a greeting delay (forced
retry) for new IPs would be extremely effective, too. It was my next
feature to try...

-George


On Fri, Aug 26, 2022 at 10:20 AM Andy Bradford <
amb-sendok-1664126422.hkaoimcbaknehlhpgjnd@bradfords.org> wrote:

> Thus said George Georgalis on Fri, 26 Aug 2022 07:15:20 -0700:
>
> > I switched my MX to Google when maintaining spam filters became too
> > time consuming... I would like to unplug from Google now, but I am
> > afraid of the consequences.
>
> That's interesting. I haven't dedicated much time to spam filters
> lately, and I have less spam than I ever did when I used Gmail addresses
> that I had never given out to anyone.
>
> I rely mostly upon RBLs at this point, but I do still see a lot of email
> that is "blocked" due to greeting delay and protocol violations.
>
> Andy
>
>

--
George Georgalis, (415) 894-2710, http://www.galis.org/
Re: Google & STARTTLS [ In reply to ]
Thus said George Georgalis on Fri, 26 Aug 2022 11:59:36 -0700:

> IIRC the time consuming part was clamdscan,

Yes, virus scanning is the biggest time and resource sink. I don't think
it's worth it, just run better client software. :-)

> I used a script to convert registrar country codes (bad actors) to ip
> for rbl processing by ipsvd (big win) and I expect a greeting delay
> (forced retry) for new IPs would be extremely effective, too. It was
> my next feature to try...

Here's a breakdown of the effectiveness of various techniques gleaned
from the qmail-smtpd (tcpserver really) logs:

$ cat @* current | grep -c 'pid .* from .*'
20613
$ cat @* current | grep -c 'rblsmtpd'
15282
$ cat @* current | grep -c 'greetdelay: client sent data'
1604
$ cat @* current | grep -c 'greetingdelay: client disconnected'
94

Your definition of greeting delay seems different though. I'm not sure
what "(forced retry)" means. The greeting delay that I use is basically
a fixed amount of sleep time that is imposed before the banner is
returned to the connected client. There is no retry required as long as
the SMTP client remains connected for the duration of the presentation
of the banner. If they disconnected before the banner arrives, no
message will be delivered. If they fire and forget without waiting for
the banner, no message will be delivered.

Perhaps you're thinking of greylisting? If so, I can also attest that
greylisting is extremely effective against all the infected PCs and
systems out there that are not actually MTAs, but just delivering junk.
I've found this extremely helpful in this regard:

http://man.openbsd.org/spamd

Andy
Re: Google & STARTTLS [ In reply to ]
On Fri, Aug 26, 2022 at 7:46 PM Andy Bradford
<amb-sendok-1664160378.ngebjdpbidpbmmoldpbd@bradfords.org> wrote:
>
> Thus said George Georgalis on Fri, 26 Aug 2022 11:59:36 -0700:
>
> > IIRC the time consuming part was clamdscan,
>
> Yes, virus scanning is the biggest time and resource sink. I don't think
> it's worth it, just run better client software. :-)

Actually, I was referring to consumption of administrative time. There
was a lot of virus circulating from infected clients to addresses
harvested from their local storage, and clamav was very efficient
scanning those.

Yes, greylisting is what I was referring to, good test. I don't like
the idea of greeting delay, imagine if all smtp did that?

This has been an informative conversation. What works for most mail,
most of the time prevails. A friend never receives my email from
google to hotmail, not in spam, no bounce/reject notice, just no
delivery. I guess they think RFC is not so important if most of the
mail usually goes through... we aren't the customers, just the users.
I'd also like to get something done about my audio dropouts in voip
calls, due to my ISP and their peering. Realistically, what can you
do?

smtp is a robust protocol, and I like the notion of obligated
delivery. A crypto compatible equivalent of the German impressum
requirement could solve a lot of problems too. Imagine if an openpgp
ring of trust was the gold standard for identity. It is such a good
solution that everyone should participate, right? Maybe people don't
want to be accountable for their own identity? Maybe the client is too
difficult? I guess there's just no incentive when xP2P communication
achieves the needful? Thanks for reading.




--
George Georgalis, (415) 894-2710, http://www.galis.org/
Re: Google & STARTTLS [ In reply to ]
Thus said George Georgalis on Sat, 27 Aug 2022 11:47:19 -0700:

> I don't like the idea of greeting delay, imagine if all smtp did that?

This might shed a different light on the matter:

http://www.armory.com/~spcecdt/spamware/

As far as what would happen if all SMTP did that? It would likely have
minimal impact on legitimate senders. As for the impact on spammers;
it's hard to say because the reason why it's effective is because SPAM
sources are often not legitimate MTAs and don't implement RFC-compliant
behaviors (like waiting for banners) so they are easily confused by
small delays. Maybe if everyone did it, spammers would adapt? So far it
remains effective as far as I can tell.

From the statistics that I provided you can easily see that a greeting
delay accounted for blocking 8.23% of connections and 9.44% of all spam
effort. Also, in my particular instance, I only impose a greeting delay
if the "reverse" DNS for the connecting client is misconfigured. I
imagine that greeting delay would be even more effective if I removed
this minor concession.

Andy

1 2  View All