Mailing List Archive

Google & STARTTLS
Just a FYI...

A little while ago, there was mention that Google/Gmail was not delivering
mail to MXes that didn't support STARTTLS, and indeed I noticed this. Senders
would compose and send a message with apparent success, but Gmail servers
simply wouldn't progress past HELO/EHLO, and didn't inform the sender the
message hadn't been delivered.

Implementing STARTTLS support in qmail-smtpd suddenly got a lot more
important, even for sites that use encrypted mail for anything sensitive.

The other shoe now appears to have dropped. I don't know if this has rolled
out widely, but about a week ago (at least for me) Gmail started silently
roundfiling all incoming mail where STARTTLS was not used in the connection.
They did their usual thing of acknowledging receipt/responsibility for the
messages, but recipients simply wouldn't get them - and not in junk/spam
folders either.

So now qmail-remote STARTTLS support is pretty critical as well.

I'd be interested to hear if others have been noticing this lately. The "but
do it silently" aspect of both of these changes is the most frustrating thing
about it.

Charles
--
--------------------------------------------------------------------------
Charles Cazabon
GPL'ed software available at: http://pyropus.ca/software/
Read http://pyropus.ca/personal/writings/12-steps-to-qmail-list-bliss.html
--------------------------------------------------------------------------
Re: Google & STARTTLS [ In reply to ]
On Mon, Aug 22, 2022, Charles Cazabon wrote:

> out widely, but about a week ago (at least for me) Gmail started silently
> roundfiling all incoming mail where STARTTLS was not used in the connection.

Did you test with a different MTA (or even openssl s_client)
to see whether "just" using STARTTLS makes a difference?
Maybe there are also other things at gmail which changed?
Re: Google & STARTTLS [ In reply to ]
Hi Charles,

Am Montag, dem 22.08.2022 um 20:54 -0600 schrieb Charles Cazabon:
> Just a FYI...
>
> A little while ago, there was mention that Google/Gmail was not
> delivering
> mail to MXes that didn't support STARTTLS, and indeed I noticed
> this.  Senders
> would compose and send a message with apparent success, but Gmail
> servers
> simply wouldn't progress past HELO/EHLO, and didn't inform the sender
> the
> message hadn't been delivered.
>
> Implementing STARTTLS support in qmail-smtpd suddenly got a lot more
> important, even for sites that use encrypted mail for anything
> sensitive.
>
> The other shoe now appears to have dropped.  I don't know if this has
> rolled
> out widely, but about a week ago (at least for me) Gmail started
> silently
> roundfiling all incoming mail where STARTTLS was not used in the
> connection.
> They did their usual thing of acknowledging receipt/responsibility
> for the
> messages, but recipients simply wouldn't get them - and not in
> junk/spam
> folders either.

yeah, the big guys do what they want. Currently; I'm implementing DKIM
into s/qmail (pain in the a../neck). Google is using DMARC for
notification. Even if my DKIM signature is wrong, mail goes thru. 

The time delay upon receipt however shows me, that they have internally
a HUGE spam detecting logic using massive caches. Probably, they have

https://content-security-policy.com/

(CSP) in place as well. It is getting more and more crazy.

You know: Going on a plane, a bottle or a tube is restricted to 75ml
content only (on board). Having more is dangerous and considered a
weapon.
These days, a SMTP mail seems to be a threat and weapon as well.

ASCII code is deadly weapon \->+/ ;-)

Regards.
--eh.

>
> So now qmail-remote STARTTLS support is pretty critical as well.
>
> I'd be interested to hear if others have been noticing this lately. 
> The "but
> do it silently" aspect of both of these changes is the most
> frustrating thing
> about it.
>
> Charles

--
Dr. Erwin Hoffmann | www.fehcom.de
PGP key-id: 20FD6E671A94DC1E
PGP key-fingerprint: 8C6B 155B 0FDA 64F1 BCCE A6B9 20FD 6E67 1A94 DC1E
Re: Google & STARTTLS [ In reply to ]
Hi, Claus,

Thanks for the response.

Claus Assmann <qmail@esmtp.org> wrote:
> On Mon, Aug 22, 2022, Charles Cazabon wrote:
>
> > out widely, but about a week ago (at least for me) Gmail started silently
> > roundfiling all incoming mail where STARTTLS was not used in the connection.
>
> Did you test with a different MTA (or even openssl s_client)
> to see whether "just" using STARTTLS makes a difference?

I implemented STARTTLS - the only change to my qmail-remote replacement - and
the very next message (and all following it) was delivered to the Gmail-hosted
recipients. I turned off STARTTLS to double-check, and the very next message,
and a few more following it (I disabled the test after that) disappeared into
the aether.

It was a pretty well-controlled experiment. I had originally thought I would
need to implement DKIM to get in their good books again, but at this point it
seems just STARTTLS is enough.

> Maybe there are also other things at gmail which changed?

Perhaps - but just STARTTLS is sufficient for now.

Charles
--
--------------------------------------------------------------------------
Charles Cazabon
GPL'ed software available at: http://pyropus.ca/software/
Read http://pyropus.ca/personal/writings/12-steps-to-qmail-list-bliss.html
--------------------------------------------------------------------------
Re: Google & STARTTLS [ In reply to ]
Erwin Hoffmann <feh@fehcom.de> wrote:
> >
> > about a week ago (at least for me) Gmail started silently roundfiling all
> > incoming mail where STARTTLS was not used in the connection.
>
> yeah, the big guys do what they want.

900lb gorilla of email. Where does one find a Great Hunter with a primate
fetish these days?

> Currently; I'm implementing DKIM into s/qmail (pain in the a../neck). Google
> is using DMARC for notification. Even if my DKIM signature is wrong, mail
> goes thru. 

I was surprised that just adopting STARTTLS on the outgoing connection was
sufficient to get mail through; I assumed I would have to add DKIM as well.
Adding DIM to qmail-remote looked like a huge pain to me too, so I wrote a
qmail-remote replacement instead, with STARTTLS by default.

I'll probably still add DKIM to it at some point. Might as well.

Charles
--
--------------------------------------------------------------------------
Charles Cazabon
GPL'ed software available at: http://pyropus.ca/software/
Read http://pyropus.ca/personal/writings/12-steps-to-qmail-list-bliss.html
--------------------------------------------------------------------------
Re: Google & STARTTLS [ In reply to ]
On Tue, 23 Aug 2022 at 18:49, Charles Cazabon
<search-web-for-address@pyropus.ca> wrote:

> I was surprised that just adopting STARTTLS on the outgoing connection was
> sufficient to get mail through; I assumed I would have to add DKIM as well.
> Adding DIM to qmail-remote looked like a huge pain to me too, so I wrote a
> qmail-remote replacement instead, with STARTTLS by default.
>
> I'll probably still add DKIM to it at some point. Might as well.

DKIM, SPF and DMARC are useful when you are a mass mailer and you need
to take action on reports generated for DKIM/SPF failure. As of now I
haven't seen it being used by gmail to reject mails just because the
mail did not have a DKIM signature.
STARTTLS is good enough but occasionally there is the pain of updating
the code because of changes to openssl functions. I have STARTTLS in
qmail-smtpd and qmail-remote since 2003, and have experienced openssl
functions getting deprecated, having to change things because of
discovery of new vulnerability in openssl, etc. And the state of the
openssl, crypto libraries will be different on different distributions
and you end up with few #ifdefs to handle all environments during a
transition period.
--
Regards Manvendra - http://www.indimail.org
GPG Pub Key
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC7CBC760014D250C
Re: Google & STARTTLS [ In reply to ]
Manvendra Bhangui <mbhangui@gmail.com> wrote:
> >
> > I'll probably still add DKIM to it at some point. Might as well.
>
> DKIM, SPF and DMARC are useful when you are a mass mailer and you need
> to take action on reports generated for DKIM/SPF failure.

I added SPF and DMARC records for my domains years ago. But it pisses me off
that so many mail receivers implement that damn thing incorrectly - the SPF
standard says you check the envelope sender against the published SPF policy,
not any addresses from the message header content. But every time I post to a
mailing list I get a bunch of DMARC failure reports showing that the receiver
tested the From: header address instead of the envelope sender.

I presume a lot of this is from people using dumb mail forwarding that uses
the original message's From: header address as the envelope sender when
forwarding it.

> As of now I haven't seen it being used by gmail to reject mails just because
> the mail did not have a DKIM signature.

I haven't seen this either. It might be useful, but implementing it is not on
my radar at the moment. If anyone ever implemented this for qmail, I would
guess it might have been Russ Nelson - IIRC, he was involved in the original
DomainKeys specification before it merged with the other thing to become DKIM.

Charles
--
--------------------------------------------------------------------------
Charles Cazabon
GPL'ed software available at: http://pyropus.ca/software/
Read http://pyropus.ca/personal/writings/12-steps-to-qmail-list-bliss.html
--------------------------------------------------------------------------
Re: Google & STARTTLS [ In reply to ]
On Tue, 23 Aug 2022 at 21:33, Charles Cazabon
<search-web-for-address@pyropus.ca> wrote:

> I haven't seen this either. It might be useful, but implementing it is not on
> my radar at the moment. If anyone ever implemented this for qmail, I would
> guess it might have been Russ Nelson - IIRC, he was involved in the original
> DomainKeys specification before it merged with the other thing to become DKIM.

Russ wrote qmail-dk as a QMAILQUEUE replacement to implement
DomainKeys for qmail. I used his idea to implement qmail-dkim as a
QMAILQUEUE replacement using libdkim library from ALT-N technologies.
It is also part of indimail-mta but more heavily used by folks who
follow Roberto's qmail notes page. Over the years, the DKIM patch for
netqmail has gotten robust due to feedback from Roberto and his users,
resulting in a lot of bug fixes in the ALT-N libdkim and also my own
code. The libdkim library has issues especially with the DNS
functions. Ultimately, I replaced the DNS functions with those from
qmail.

https://notes.sagredo.eu/en/qmail-notes-185/configuring-dkim-for-qmail-92.html

--
Regards Manvendra - http://www.indimail.org
GPG Pub Key
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC7CBC760014D250C
Re: Google & STARTTLS [ In reply to ]
It appears that Manvendra Bhangui <mbhangui@gmail.com> said:
>On Tue, 23 Aug 2022 at 18:49, Charles Cazabon
><search-web-for-address@pyropus.ca> wrote:
>
>> I was surprised that just adopting STARTTLS on the outgoing connection was
>> sufficient to get mail through; I assumed I would have to add DKIM as well.
>> Adding DIM to qmail-remote looked like a huge pain to me too, so I wrote a
>> qmail-remote replacement instead, with STARTTLS by default.
>>
>> I'll probably still add DKIM to it at some point. Might as well.
>
>DKIM, SPF and DMARC are useful when you are a mass mailer and you need
>to take action on reports generated for DKIM/SPF failure. As of now I
>haven't seen it being used by gmail to reject mails just because the
>mail did not have a DKIM signature.

You would if you sent over IPv6. Given the vast amount of spam and phish
sent every minute, mail systems are only going to get stricter about what
they accept. I'm kind of surprised that so many mail systems still accept
mail without STARTTLS at all.

R's,
John
Re: Google & STARTTLS [ In reply to ]
Thus said Charles Cazabon on Mon, 22 Aug 2022 20:54:31 -0600:

> I'd be interested to hear if others have been noticing this lately.
> The "but do it silently" aspect of both of these changes is the most
> frustrating thing about it.

I have not noticed it, but then, I don't have a huge SMTP presence
either.

I agree that silently dropping things is the most frustrating. It shows
that they don't really care about their "customers" and only have an axe
to grind. Gmail has been silently disappearing emails for some time now,
so this is just par for the course.

Andy
Re: Google & STARTTLS [ In reply to ]
Thus said "John Levine" on 23 Aug 2022 13:14:22 -0400:

> You would if you sent over IPv6. Given the vast amount of spam and
> phish sent every minute, mail systems are only going to get stricter
> about what they accept. I'm kind of surprised that so many mail
> systems still accept mail without STARTTLS at all.

The fact is, nobody knows how many mail systems still accept mail
without STARTTLS. If people want encryption, they aren't going to get it
for free using STARTTLS. Gmail knows this, I have a hard time believing
that they are doing this to improve the security or privacy of their
"customers" email.

The problem is that the "customers" don't actually have any say in the
matter. They don't even know what's happening, nor do they probably
care. But my guess is that they probably don't care about STARTTLS or if
a given recipient of theirs runs an MTA that doesn't support STARTTLS.

The only real way to secure email is to encrypt it _before_ sending it
through Gmail.

It would be really interesting to perform a study similar to the 2001
Qmail survey:

http://web.archive.org/web/20220410102151/http://cr.yp.to/surveys/smtpsoftware6.txt

To see just how many SMTP servers actually do advertise STARTTLS.

Andy
Re: Google & STARTTLS [ In reply to ]
> The fact is, nobody knows how many mail systems still accept mail
> without STARTTLS.

I've done some scans of SMTP servers for other reasons. I'll see about
twiddling the code to scan and look for STARTTLS. I would be surprised if
I found a lot of MX servers that don't do STARTTLS now.

If people want encryption, they aren't going to get it
> for free using STARTTLS. Gmail knows this, I have a hard time believing
> that they are doing this to improve the security or privacy of their
> "customers" email.

"Encryption" isn't one thing. End-to-end encryption is swell but after
several decades of people not using S/MIME or PGP despite it being built
into most desktop and mobile mail programs, it's not going to happen.
STARTTLS is for a different threat, snoooping in transit. Combined with
MTA-STS, which was largely Google's idea, it at least keeps random
strangers from looking at your mail.

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
Re: Google & STARTTLS [ In reply to ]
Andy Bradford <amb-sendok-1663976074.hapkbimijfaakfdleank@bradfords.org>
wrote:
>
> Gmail knows this, I have a hard time believing that they are doing this
> to improve the security or privacy of their "customers" email.
>
> The problem is that the "customers" don't actually have any say in the
> matter. They don't even know what's happening, nor do they probably
> care.

I have long thought Gmail's constantly-increasing difficulty of actually
getting your messages into Gmail users' inboxes had less to do with
"anti-spam" measures than to Google trying to turn internet mail into a walled
garden. If only the big providers have the resources and/or agreements to get
messages into other providers' systems, most people will just migrate to using
those big providers rather than trying to fight the system.

Whether you think that makes me a tinfoil-hat wearer or not, it is difficult
not to see the endless hoops Google puts up and which postmasters without tens
of millions of users have to jump through as an intentional barrier of some
sort.

Charles
--
--------------------------------------------------------------------------
Charles Cazabon
GPL'ed software available at: http://pyropus.ca/software/
Read http://pyropus.ca/personal/writings/12-steps-to-qmail-list-bliss.html
--------------------------------------------------------------------------
Re: Google & STARTTLS [ In reply to ]
It appears that Charles Cazabon <search-web-for-address@pyropus.ca> said:
>Whether you think that makes me a tinfoil-hat wearer or not, it is difficult
>not to see the endless hoops Google puts up and which postmasters without tens
>of millions of users have to jump through as an intentional barrier of some
>sort.

It's definitely an intentional barrier, but it's not aimed at you, it's aimed
at mail systems that try to send literally billions of spam and phish to Gmail
and other large providers every day.

Before anyone says "but they shouldn't be filtering me, I am nice",
that is much harder to determine at scale that you can imagine if you
haven't worked on a very large mail system. Spambots tend to be
sloppily written and not to do the things that modern real MTAs do, so
if you want your mail to be delivered, it really helps to look like
an MTA and not a spambot. STARTTLS is part of that.

There are plenty of patched versions of qmail-remote that can do STARTTLS.
It shouldn't be a big deal.

R's,
John
Re: Google & STARTTLS [ In reply to ]
John Levine <johnl@iecc.com> wrote:
> >of millions of users have to jump through as an intentional barrier of some
> >sort.
>
> It's definitely an intentional barrier, but it's not aimed at you, it's
> aimed at mail systems that try to send literally billions of spam and phish
> to Gmail and other large providers every day.

Indeed. But it seems as though getting legitimate email through to
Gmail-hosted domains is an order of magnitude more difficult than the other
mega-scale mail services. I don't have problems with Yahoo or Yandex or AOL
or Outlook/whatever-MS-calls-their-service-these-days or whatever - but Gmail
is a constantly-changing pain in the ass.

> There are plenty of patched versions of qmail-remote that can do STARTTLS.
> It shouldn't be a big deal.

I implemented STARTTLS on outgoing mail a bit ago. Mail went through reliably
for a while, and now it's round-filed again after acknowledging receipt. My
domains have never sent spam or abuse or relayed or anything like that - the
worst is the odd subscriber to a mailing list who either accidentally files a
list message as spam, or spends two seconds trying to unsubscribe before
deciding it's too hard and clicks whatever button in the Gmail UI - is there a
"block (or report) this sender" button?

They're all ezmlm-idx lists. No one has ever been signed up without
permission. And they're not marketing, or commercial, at all - technical
lists, an announcement list for a journalist's new columns, etc.

I'm working on outbound DKIM signing now, but history suggests it won't be a
panacea - at least not for long.

Charles
--
--------------------------------------------------------------------------
Charles Cazabon
GPL'ed software available at: http://pyropus.ca/software/
Read http://pyropus.ca/personal/writings/12-steps-to-qmail-list-bliss.html
--------------------------------------------------------------------------
Re: Google & STARTTLS [ In reply to ]
It appears that Charles Cazabon <search-web-for-address@pyropus.ca> said:
>Indeed. But it seems as though getting legitimate email through to
>Gmail-hosted domains is an order of magnitude more difficult than the other
>mega-scale mail services. I don't have problems with Yahoo or Yandex or AOL
>or Outlook/whatever-MS-calls-their-service-these-days or whatever - but Gmail
>is a constantly-changing pain in the ass.

I dunno, I send lots of mail to Gmail over IPv6 and it works fine.

Of course, I do SPF, DKIM, and STARTTLS.

>They're all ezmlm-idx lists. No one has ever been signed up without
>permission. And they're not marketing, or commercial, at all - technical
>lists, an announcement list for a journalist's new columns, etc.

Does the list DKIM sign the mail? Is there SPF for the bounce address?

Also, what other mail does that IP send?

R's,
John
Re: Google & STARTTLS [ In reply to ]
John Levine <johnl@iecc.com> wrote:
>
> Of course, I do SPF, DKIM, and STARTTLS.

I'm currently using SPF and STARTTLS.

> >They're all ezmlm-idx lists. No one has ever been signed up without
> >permission. And they're not marketing, or commercial, at all - technical
> >lists, an announcement list for a journalist's new columns, etc.
>
> Does the list DKIM sign the mail?

Not yet. I'm working on implementing DKIM signing.

> Is there SPF for the bounce address?

Yes. All domains handled by this machine have valid SPF records.

> Also, what other mail does that IP send?

Not a lot. Two personal domains, one which does virtually 0 mail, and the
other which is solely my outgoing messages, and two list domains. The first
has a bunch of lists that are almost always idle, plus the getmail-users list
which used to be fairly active but now rarely hits 10 messages a month. The
other list domain hosts a single announce list, with 1-4 messages per month.

I guess that's what bugs me. My domains have never sent spam, I've never had
a machine get turned into a malefactor's bot, I've had the same server IP
address for more than a decade, and that's never sent spam... so I've been a
good netizen, and I still feel helpless in trying to reliably get mail through
to Gmail-hosted domains.

Because if you can't reliably deliver messages to Gmail users, you might as
well be running an intranet mail server, take your ball, and go home.

Maybe I should forget email and go maintain sewers :)

Charles
--
--------------------------------------------------------------------------
Charles Cazabon
GPL'ed software available at: http://pyropus.ca/software/
Read http://pyropus.ca/personal/writings/12-steps-to-qmail-list-bliss.html
--------------------------------------------------------------------------
Re: Google & STARTTLS [ In reply to ]
Thus said Charles Cazabon on Thu, 25 Aug 2022 16:38:21 -0600:

> Indeed. But it seems as though getting legitimate email through to
> Gmail-hosted domains is an order of magnitude more difficult than the
> other mega-scale mail services.

I have also made this same observation over the years. As soon as Gmail
started accepting and then disappearing emails (e.g. no notification to
sender of problem or no notification to recipient that they disposed of
a message directed to them) I started recommending Hotmail and other
services. These days I recommend ProtonMail, though, I'm not opposed to
discovering better services, but I will never recommend Gmail at this
point.

Thanks,

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

silent dropping of E-Mail is a criminal offense in Germany and should be
everywhere else.

Regards,

Michael Brunnbauer

On Thu, Aug 25, 2022 at 12:40:20PM -0400, John Levine wrote:
> It's definitely an intentional barrier, but it's not aimed at you, it's aimed
> at mail systems that try to send literally billions of spam and phish to Gmail
> and other large providers every day.
>
> Before anyone says "but they shouldn't be filtering me, I am nice",
> that is much harder to determine at scale that you can imagine if you
> haven't worked on a very large mail system. Spambots tend to be
> sloppily written and not to do the things that modern real MTAs do, so
> if you want your mail to be delivered, it really helps to look like
> an MTA and not a spambot. STARTTLS is part of that.
>
> There are plenty of patched versions of qmail-remote that can do STARTTLS.
> It shouldn't be a big deal.
>
> R's,
> John

--
++ Michael Brunnbauer
++ netEstate GmbH
++ Geisenhausener Stra?e 11a
++ 81379 M?nchen
++ Tel +49 89 32 19 77 80
++ Fax +49 89 32 19 77 89
++ E-Mail brunni@netestate.de
++ https://www.netestate.de/
++
++ Sitz: M?nchen, HRB Nr.142452 (Handelsregister B M?nchen)
++ USt-IdNr. DE221033342
++ Gesch?ftsf?hrer: Michael Brunnbauer, Franz Brunnbauer
++ Prokurist: Dipl. Kfm. (Univ.) Markus Hendel
Re: Google & STARTTLS [ In reply to ]
Michael Brunnbauer <brunni@netestate.de> wrote:
>
> silent dropping of E-Mail is a criminal offense in Germany and should be
> everywhere else.

That's fascinating... do you have a reference? Unfortunately I can't see the
Americans making it illegal. Maybe here in Canada...

Charles
--
--------------------------------------------------------------------------
Charles Cazabon
GPL'ed software available at: http://pyropus.ca/software/
Read http://pyropus.ca/personal/writings/12-steps-to-qmail-list-bliss.html
--------------------------------------------------------------------------
Re: Google & STARTTLS [ In reply to ]
Am 26.08.22 um 14:58 schrieb Charles Cazabon:
> Michael Brunnbauer <brunni@netestate.de> wrote:
>>
>> silent dropping of E-Mail is a criminal offense in Germany and should be
>> everywhere else.
>
> That's fascinating... do you have a reference? Unfortunately I can't see the
> Americans making it illegal. Maybe here in Canada...

We have something (in German) on our website:

https://www.heinlein-support.de/presse/pressemitteilung/spam-folder-bergen-haftungsrisiken-fuer-unternehmen-und-privatpersonen

It basically boils down to: as soon as the recipient's mailserver has
accepted the message the receiver is responsible for it.

If the receiver has a SPAM folder or does quarantine suspicious emails
they have to look at them every day for false positives.

The same applies if you just throw away suspicious emails. They could be
false positives and contain important commercial informations.

This is why we reject while still being in the SMTP dialogue. This way
the sender gets notified that there was no delivery.

Regards
--
Robert Sander
gurubert.de
Re: Google & STARTTLS [ In reply to ]
Hello Robert,

On Fri, Aug 26, 2022 at 03:08:03PM +0200, Robert Sander wrote:
> > > silent dropping of E-Mail is a criminal offense in Germany and should be
> > > everywhere else.
> > That's fascinating... do you have a reference? Unfortunately I can't see the
> > Americans making it illegal. Maybe here in Canada...
> We have something (in German) on our website:
>
> https://www.heinlein-support.de/presse/pressemitteilung/spam-folder-bergen-haftungsrisiken-fuer-unternehmen-und-privatpersonen

No that's not what I meant. I meant this:

https://www.gesetze-im-internet.de/stgb/__206.html
https://oberlandesgericht-karlsruhe.justiz-bw.de/pb/,Lde/1150475/?LISTPAGE=1150395
https://www.rz.uni-wuerzburg.de/fileadmin/42010000/it-recht/Strafbarkeitsrisiken_bei_E-Mail-Schutzmassnahmen.pdf

As you can see, it's a mess. I should have said "can be criminal offense",
not "is a criminal offense".

Regards,

Michael Brunnbauer

--
++ Michael Brunnbauer
++ netEstate GmbH
++ Geisenhausener Stra?e 11a
++ 81379 M?nchen
++ Tel +49 89 32 19 77 80
++ Fax +49 89 32 19 77 89
++ E-Mail brunni@netestate.de
++ https://www.netestate.de/
++
++ Sitz: M?nchen, HRB Nr.142452 (Handelsregister B M?nchen)
++ USt-IdNr. DE221033342
++ Gesch?ftsf?hrer: Michael Brunnbauer, Franz Brunnbauer
++ Prokurist: Dipl. Kfm. (Univ.) Markus Hendel
Re: Google & STARTTLS [ In reply to ]
Am 26.08.22 um 15:56 schrieb Michael Brunnbauer:
>
> Hello Robert,
>
> On Fri, Aug 26, 2022 at 03:08:03PM +0200, Robert Sander wrote:
>>>> silent dropping of E-Mail is a criminal offense in Germany and should be
>>>> everywhere else.
>>> That's fascinating... do you have a reference? Unfortunately I can't see the
>>> Americans making it illegal. Maybe here in Canada...
>> We have something (in German) on our website:
>>
>> https://www.heinlein-support.de/presse/pressemitteilung/spam-folder-bergen-haftungsrisiken-fuer-unternehmen-und-privatpersonen
>
> No that's not what I meant. I meant this:
>
> https://www.gesetze-im-internet.de/stgb/__206.html
> https://oberlandesgericht-karlsruhe.justiz-bw.de/pb/,Lde/1150475/?LISTPAGE=1150395
> https://www.rz.uni-wuerzburg.de/fileadmin/42010000/it-recht/Strafbarkeitsrisiken_bei_E-Mail-Schutzmassnahmen.pdf
>
> As you can see, it's a mess. I should have said "can be criminal offense",
> not "is a criminal offense".

In the end both have the same effect:

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.

Regards
--
Robert Sander
gurubert.de
Re: Google & STARTTLS [ In reply to ]
On Fri, Aug 26, 2022 at 6:10 AM Robert Sander <gurubert@gurubert.de> wrote:

>
> This is why we reject while still being in the SMTP dialogue. This way
> the sender gets notified that there was no delivery.
>
>
Such a profoundly simple solution!

When I was receiving SMTP, in addition to rejecting spam during
transaction, I retained the message in a user accessible spam folder. This
is convenient for false positives because the sender could notify the
recipient out of band, and the recipient could then conveniently retrieve
the message, with the requisite filter parameters to report in the header.

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.

-George

--
George Georgalis, (415) 894-2710, http://www.galis.org/
Re: Google & STARTTLS [ In reply to ]
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

1 2  View All