Re: [mailop] Mimecast Adimin Probation Block - 74.203.49.59

[Sebastian Nielsen via mailop]

>>See RFC 8058 on doing one-click unsubs in a way unlikely to be mistriggered.  

Its a good idea, but don't count on all MUAs implementing this function, so 
best here is to have both, if request arrives from the RFC 8058 header, treat 
it as secure enough to warrant one-click, but if it arrives through the 
unsubscribe link in the email itself, require an extra click on button.

Thus those with non-RFC8058-aware MUAs can still unsubscribe, but it will 
require an extra click.

Some MUAs implement RFC 8058 through their Junk button, so you actually have to 
click Junk to trigger RFC 8058, which then both reports the mail as Junk but 
also triggers a RFC 8058 Post.

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Mimecast Adimin Probation Block - 74.203.49.59

[John Levine via mailop]

It appears that Grant Taylor via mailop  said:
>On 6/28/23 11:07 AM, Chris Truitt via mailop wrote:
>> The Mimecast spam checking appears to be clicking every link. This has 
>> inadvertently caused an uptick in Unsubscribes.
>
>Aside:  Isn't this why the unsubscribe links are encouraged to use / 
>require a POST so that simple GETs don't accidentally trigger the 
>unsubscribe?

Yes indeed. Lots of mail systems fetch all the URLs as part of spam
filtering, so if you misinterpret them you have worse problems than
Mimecast.

See RFC 8058 on doing one-click unsubs in a way unlikely to be mistriggered.  

You can require an extra click but that is more annoying to the users
than POST, and we are doing you a favor by unsubbscribing (the junk
button is always one click) so it is in your interest to make it as
easy as possible.

R's,
John
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Mimecast Adimin Probation Block - 74.203.49.59

[Sebastian Nielsen via mailop]

No, but a 2-step procedure is recommended. Click the link, then push a button 
to confirm.
Some actors also require a checkbox, to really make sure link-following bots 
don't confirm. Or even a simple captcha.
Don’t neccessarly need to use POST, but scanning systems scan the links to 
ensure no malicious software is there or similar.

So just making the unsubscribe request in a second link is enough, scanning 
bots don't follow more than 1 step in most cases, and for 2-step following 
bots, a checkbox is enough to veer them off.
If they feel the urge of following subsequent links to check for malice, they 
will also follow POST based links, else malware actors could just hide 
everything behind a POST.

POST/GET is only to prevent certain caching and reloading behaviour to affect 
things on a server, for example, reloading a page might delete something or 
similar.

-Ursprungligt meddelande-
Från: Grant Taylor via mailop  
Skickat: den 28 juni 2023 22:22
Till: mailop@mailop.org
Ämne: Re: [mailop] Mimecast Adimin Probation Block - 74.203.49.59

On 6/28/23 11:07 AM, Chris Truitt via mailop wrote:
> The Mimecast spam checking appears to be clicking every link. This has 
> inadvertently caused an uptick in Unsubscribes.

Aside:  Isn't this why the unsubscribe links are encouraged to use / 
require a POST so that simple GETs don't accidentally trigger the 
unsubscribe?



Grant. . . .
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Mimecast Adimin Probation Block - 74.203.49.59

[Grant Taylor via mailop]

On 6/28/23 11:07 AM, Chris Truitt via mailop wrote:
The Mimecast spam checking appears to be clicking every link. This has 
inadvertently caused an uptick in Unsubscribes.


Aside:  Isn't this why the unsubscribe links are encouraged to use / 
require a POST so that simple GETs don't accidentally trigger the 
unsubscribe?




Grant. . . .
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] greylisting, SendGrid is deleting your mail

[John Levine via mailop]

It appears that Gellner, Oliver via mailop  said:
>> That occasionally happens, but since I whitelist any /24 that has 
>> successfully retried, it doesn't happen very much.
>
>I see, this looks like a better approach. Unfortunately many greylisting 
>implementations only whitelist senders for a few days or even
>less. Or they fail to sync connections across different MTAs / regions. 

There's an unfortunate tendency for people to imagine that if X is a
useful anti-spam measure, doing more X is better, which is usually wrong. 
Greylisting everything is worse than just greylisting unknown hosts, and
a 5 second greet pause delay works as well as 5 minutes.

My greylister remembers hosts for 90 days, on the theory that if they
haven't sent mail for three months, they probably won't send mail
ever. It also has a single daemon shared among all the MTAs to track
the retries and whitelist.

I recently added a greet pause for hosts subject to greylisting and I
have to admit it works pretty well. Most of the hosts that get the
pause are early talkers. It appears that nearly all hosts that aren't
also retry. If that continues to be true, I'll just ditch the retries
since the greet pause is less disruptive.

R's,
John
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Mimecast Adimin Probation Block - 74.203.49.59

[Dave Smith via mailop]

Replied offline.

From: mailop  on behalf of Chris Truitt via mailop 

Date: Wednesday, June 28, 2023 at 12:11 PM
To: Dave Smith via mailop 
Subject: [mailop] Mimecast Adimin Probation Block - 74.203.49.59
Hi Dave,

We're getting a Mimecast Admin Probation Block.
The Mimecast spam checking appears to be clicking every link. This has 
inadvertently caused an uptick in Unsubscribes.

smtp;550 Administrative prohibition - envelope blocked - 
https://community.mimecast.com/docs/DOC-1369#550 [2TjxbsUyNyGkZn1qelpfdQ.uk8].
Sending IP: 74.203.49.59

While the SMTP error on the Mimecast site indicates an issue with the SPF 
record, our tests prooves this to be false.

Are you the appropriate contact to help me with this?
If not would you mind pointing me in the right direction?

Thanks in advance,

Chris Truitt


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Mimecast Adimin Probation Block - 74.203.49.59

[Chris Truitt via mailop]

Hi Dave,

We're getting a Mimecast Admin Probation Block.
The Mimecast spam checking appears to be clicking every link. This has 
inadvertently caused an uptick in Unsubscribes.

smtp;550 Administrative prohibition - envelope blocked - 
https://community.mimecast.com/docs/DOC-1369#550 [2TjxbsUyNyGkZn1qelpfdQ.uk8].
Sending IP: 74.203.49.59

While the SMTP error on the Mimecast site indicates an issue with the SPF 
record, our tests prooves this to be false.

Are you the appropriate contact to help me with this?
If not would you mind pointing me in the right direction?

Thanks in advance,

Chris Truitt


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] greylisting, SendGrid is deleting your mail

[Gellner, Oliver via mailop]

> On 24.06.2023 at 19:38 John Levine via mailop wrote:

> According to Gellner, Oliver via mailop :
>>
>>It matters if the greylisting takes place before or after RBL / domain
>>reputation checks. If the greylisting comes first, I could imagine that the 
>>connections from most of those bots would have been blocked anyway (with a 
>>5xx response code).

> No, this is after DNSBL checks, which catch about 85% of attempted 
> connections. Those get, ah, special handling.

>>and thereby introduces noticeable breakage into email communication. As
>>a commercial ESP I wouldn’t set it up. It’s annoying for the users when
>>they repeatedly have to wait for registration emails, order
>>confirmation with payment details, when they are on the phone with
>>someone and want to discuss a document, which just doesn’t arrive at
>>the other end, and so on. Let alone cases where messages aren’t
>>delivered at all,

> That occasionally happens, but since I whitelist any /24 that has 
> successfully retried, it doesn't happen very much.

I see, this looks like a better approach. Unfortunately many greylisting 
implementations only whitelist senders for a few days or even less. Or they 
fail to sync connections across different MTAs / regions. Example from the last 
hours (redacted):

2023-06-28 06:33 170.10.152.242 response: 4.1.0 451 'Internal resource 
temporarily unavailable - https://community.mimecast.com/docs/DOC-1369#451'
2023-06-28 07:45 207.211.30.242 response: 4.1.0 451 'Internal resource 
temporarily unavailable - https://community.mimecast.com/docs/DOC-1369#451'
2023-06-28 08:01 91.220.42.201 response: 4.1.0 451 'Internal resource 
temporarily unavailable - https://community.mimecast.com/docs/DOC-1369#451'
2023-06-28 09:04 205.139.110.141 response: 4.1.0 451 'Internal resource 
temporarily unavailable - https://community.mimecast.com/docs/DOC-1369#451'
2023-06-28 09:55 205.139.110.221 response: 4.1.0 451 'Internal resource 
temporarily unavailable - https://community.mimecast.com/docs/DOC-1369#451'
2023-06-28 10:13 62.140.10.22 response: 4.1.0 451 'Internal resource 
temporarily unavailable - https://community.mimecast.com/docs/DOC-1369#451'
2023-06-28 10:40 91.220.42.211 response: 4.1.0 451 'Internal resource 
temporarily unavailable - https://community.mimecast.com/docs/DOC-1369#451'
2023-06-28 10:41 195.130.217.241 response: 4.1.0 451 'Internal resource 
temporarily unavailable - https://community.mimecast.com/docs/DOC-1369#451'
2023-06-28 10:55 91.220.42.241 response: 4.1.0 451 'Internal resource 
temporarily unavailable - https://community.mimecast.com/docs/DOC-1369#451'
2023-06-28 11:10 207.211.30.221 response: 4.1.0 451 'Internal resource 
temporarily unavailable - https://community.mimecast.com/docs/DOC-1369#451'

It goes on like this every day, all day long. The second attempt then succeeds, 
but this is just braindead.

--
BR Oliver


dmTECH GmbH
Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe
Telefon 0721 5592-2500 Telefax 0721 5592-2777
dmt...@dm.de * www.dmTECH.de
GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927
Geschäftsführer: Christoph Werner, Martin Dallmeier, Roman Melcher

Datenschutzrechtliche Informationen
Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser 
ServiceCenter Fragen haben, bei uns einkaufen oder unser dialogicum in 
Karlsruhe besuchen, mit uns in einer geschäftlichen Verbindung stehen oder sich 
bei uns bewerben, verarbeiten wir personenbezogene Daten. Informationen unter 
anderem zu den konkreten Datenverarbeitungen, Löschfristen, Ihren Rechten sowie 
die Kontaktdaten unserer Datenschutzbeauftragten finden Sie 
hier.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop