Re: [mailop] Google Postmaster Tools

[Ken O'Driscoll via mailop]

> On 1 Apr 2024, at 10:05, Odhiambo Washington via mailop  
> wrote:
> 
>> 
>> You must reach a certain volume of messages before anything will appear.
> 
> 
> Thank you for that insight.
> 
> Do you know what the minimum volume is?

It’s a couple of hundred per day, I don’t think they publish an exact number.

Also, they often don’t show any data, regardless of daily volume, if you have a 
very poor sending reputation, i.e. they think you are a spammer.

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

Re: [mailop] Recommended ciphers used for ESMTP connections

[Ken O'Driscoll via mailop]

I think you have to consider Postel's Law here. If your cipher choices are
causing problems for your  clients, then... maybe relax them a bit?

Transport encryption is not for confidentially anyway.


Ken.

On Mon, Mar 4, 2024, 16:34 Cyril - ImprovMX via mailop 
wrote:

> Hi everyone,
>
> Some users are reaching out to us telling they have issues connecting to
> our service because of incompatibility between the set of ciphers offered
> during the connection.
>
> On our send, we decided to use the ciphers suggested by Mozilla on their
> SSL Configuration Generator (https://ssl-config.mozilla.org/) (level
> "Intermediate") but I'm aware it's more for the HTTPS connections that
> ESMTP / TLS.
>
> So maybe there is another set of ciphers recommended for creating secured
> connections in email that I'm not aware of. Do you have any recommendations
> for this or is the ones from Mozilla (Intermediate) is good enough?
>
> If you want to avoid loading the link, here are the ciphers suggested by
> them:
>
>
> Ciphers: 
> ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305
>
> Cipher
> suites: 
> TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
>
> And we only accept TLS at v1.2 and higher.
>
> Thank you in advance.
> ___
> 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] How to deal with newly RBLed subnet?

[Ken O'Driscoll via mailop]

Hi Christos,

The operator of that RBL is a regular poster here and I presume they will
be able to assist you in the case of a false positive.

Ken.

On Sat, Mar 2, 2024, 18:11 Christos Panagiotakis via mailop <
mailop@mailop.org> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hello everyone,
> I wasn't aware of the existence of this mailing list, but I was encouraged
> to reach out in hopes that someone might be able to assist me.
> We don't send mass emails, run campaigns, or engage in similar activities.
> We are an SME dealing with web hosting that recently acquired our own ASN
> and become RIPE members.
> Due to the unavailability of IPs, we purchased our first subnet from an
> ISP.
> Unfortunately, it turns out that the subnet was blacklisted, presumably by
> the previous owner, on 3-4 lists.
> We've reached out to most of them and provided the requested information
> (historical whois records, contract, purchase invoice, etc.), and they
> removed us from their lists (TrendMicro, Proofpoint, Microsoft
> SNDS/Postmaster, Spamhaus - PS: Thank you guys! ).
> However, there are web hosting companies out there, similar to ours, that
> use spamrats at the Exim level (reject).
> Every attempt to communicate with them has been unsuccessful. Clients have
> started to complain that their emails, personal emails from person to
> person, not lists or campaigns, are not being delivered.
> I don't know if they are simply ignoring me or if they think I'm some kind
> of scammer and have gotten involved in this whole process (becoming a ripe
> member, getting my own ASN, changing WHOIS details to continue sending
> ...spam...).
>   If that is what they think, I could just lease a subnet from IPXO or
> someone else... Anyway.
>
> And in every email communication with them, I never received a response
> and if I did, it was sarcastic.
> I've sent the purchase contract, I've sent the purchase invoice, I've sent
> whois records confirming that yes, the previous owner used to send spam,
> but we have no connection to that now.
> Clients are starting to complain, and we can't do anything because it's
> our first subnet. No matter what IP we change to, we still face the same
> problem. We don't have any others!
> And the whole /24 is blacklisted!
> Does anyone know an email address of someone working at spamrats who might
> be able to help?
> I really don't know what else to do. I don't know how long ago they were
> sending spam before we purchased the subnet, but we have it for about 4
> months now, and we're still blacklisted!
> I don't know where else to turn, but this particular issue has created a
> lot of problems for us out of nowhere... 2 customers already left because
> of this.
>
>
> Regards,
> - - --
> Christos Panagiotakis
> Systems and Networks Administrator
> MyIP net-Works ( https://myip.gr )
> Addr: Kanari 5 St.
>67100 Xanthi, Greece
> Tel : +30.215-215-4722
>+30.698-371-2389
>
>
> -BEGIN PGP SIGNATURE-
> Version: BCPG C# v1.8.10.0
>
> iIUEARYIAC0FAmXjZs8mHENocmlzdG9zIFBhbmFnaW90YWtpcyA8Y2hyaXNAbXlp
> cC5ncj4ACgkQK1yKsUBHIhwFigEAjIcNmK7gIjHEcYyCGGNHVVWjt+iA6HgBT5G1
> l18GtYkBALkglO580SSCTtq88dGBvVYahIZ8gLJzoj6zQkayx+AH
> =W1T2
> -END PGP SIGNATURE-
>
> ___
> 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] One click unsubscribe in mailing list messages

[Ken O'Driscoll via mailop]

Outlook has supported list-unsubscribe for at least a year, if not longer.
But, it's an add-on you need to proactively install so...


Ken.

On Sun, Feb 25, 2024, 19:47 John Levine via mailop 
wrote:

> It appears that Hans-Martin Mosner via mailop  said:
> >Yes. I'm looking at you, thunderbird...
> >
> >This should be a no-brainer, and it's a shame that the major open source
> MUA doesn't seem to support it. There's
> >probably an add-on to do this, I just can't access the thunderbird add-on
> search at the moment, so don't know for sure.
>
> There is but it hasn't been updated to work with recent versions of
> T'bird so it installs a button but the button doesn't do anything
> useful. Oh well.
>
> Still waiting for Outlook to do this, both the web site and the program.
>
>
>
> ___
> 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] Increase of SSL/TLS errors

[Ken O'Driscoll via mailop]

44 60 ed-90 06 5b 28 ca 1f 8e 70   ..8..D`...[(...p
> 0080 - e5 fe 1e 8c 49 8a 0c 53-3b 8d 56 0b ed 15 d3 af   I..S;.V.
> 0090 - 61 d6 fb 2d 72 1f 4c 74-c6 3e 1f 52 b7 90 11 45   a..-r.Lt.>.R...E
> 00a0 - 31 09 68 e5 51 73 30 05-e9 01 d8 4c 50 8d 25 e8   1.h.Qs0LP.%.
> 00b0 - a0 0b f9 12 fe 4d bd 61-65 24 f3 8e b0 82 a1 f2   .M.ae$..
> 00c0 - 69 26 69 a9 3d e9 c8 6f-ab 46 8b 20 fc 2e e8 f4   i=..o.F. 
> 00d0 - cf 54 b5 70 c5 24 70 0d-f7 29 82 b1 2e 42 c5 1b   .T.p.$p..)...B..
> 00e0 - b9 08 71 2a f8 4e bc b0-69 d7 b6 f6 cc 32 88 55   ..q*.N..i2.U
> 
> Start Time: 1694514461
> Timeout   : 7200 (sec)
> Verify return code: 0 (ok)
> Extended master secret: no
> Max Early Data: 0
> ---
> read R BLOCK
> 
> Camille
> 
> Le 12/09/2023 à 12:21, Ken O'Driscoll via mailop a écrit :
>> 
>> What do you see when you run openssl s_client -connect… against the the MTAs 
>> that are associated with this specific error in your logs?
>> 
>> Ken.
>> 
>> 
>>> On 12 Sep 2023, at 10:50, Camille - Clean Mailbox via mailop 
>>>  <mailto:mailop@mailop.org> wrote:
>>> 
>>> Ok I'm now running RSA without DST cert:
>>> # openssl crl2pkcs7 -nocrl -certfile 
>>> /etc/letsencrypt/live/clean-mailbox.com/fullchain.pem 
>>> <http://clean-mailbox.com/fullchain.pem> | openssl pkcs7 -print_certs -noout
>>> subject=CN = clean-mailbox.com <http://clean-mailbox.com/>
>>> issuer=C = US, O = Let's Encrypt, CN = R3
>>> 
>>> subject=C = US, O = Let's Encrypt, CN = R3
>>> issuer=C = US, O = Internet Security Research Group, CN = ISRG Root X1
>>> 
>>> Still:
>>> 
>>> 2023-09-12T10:48:56.708719+02:00 mx2 postfix/smtpd[406672]: SSL_accept 
>>> error from m240-158.my-hammer.de 
>>> <http://m240-158.my-hammer.de/>[159.112.240.158]: -1
>>> 2023-09-12T10:48:56.710166+02:00 mx2 postfix/smtpd[406672]: warning: TLS 
>>> library problem: error:0A000412:SSL routines::sslv3 alert bad 
>>> certificate:../ssl/record/rec_layer_s3.c:1586:SSL alert number 42:
>>> 
>>> Camille
>>> 
>>> Le 12/09/2023 à 10:15, Slavko via mailop a écrit :
>>>> Ahoj,
>>>> 
>>>> Dňa Tue, 12 Sep 2023 09:25:59 +0200 Geert Hendrickx via mailop
>>>>  <mailto:mailop@mailop.org> napísal:
>>>> 
>>>>> The reason is likely the certificate itself, not the chain; this
>>>>> server offers (only) an ECC certificate, and while the vast majority
>>>>> of clients are compatible with this today, some still only support
>>>>> RSA.
>>>> Yes, i can confirm this. My MX's stats shows that one sender still
>>>> requires RSA. Unfortunately it is my bank, thus i use dual certs ;-)
>>>> 
>>>> In other words, the MX is only one my service with dual certs. When i
>>>> start to use EC, i had dual certs for MSA too, but after some time, i
>>>> abandon the RSA, as all clients was happy with EC...
>>>> 
>>>> regards
>>>> 
>>>> 
>>>> ___
>>>> mailop mailing list
>>>> mailop@mailop.org <mailto:mailop@mailop.org>
>>>> https://list.mailop.org/listinfo/mailop
>>> ___
>>> mailop mailing list
>>> mailop@mailop.org <mailto:mailop@mailop.org>
>>> https://list.mailop.org/listinfo/mailop
>> 
>> 
>> 
>> ___
>> mailop mailing list
>> mailop@mailop.org <mailto:mailop@mailop.org>
>> https://list.mailop.org/listinfo/mailop
> ___
> 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] Increase of SSL/TLS errors

[Ken O'Driscoll via mailop]

What do you see when you run openssl s_client -connect… against the the MTAs 
that are associated with this specific error in your logs?

Ken.


> On 12 Sep 2023, at 10:50, Camille - Clean Mailbox via mailop 
>  wrote:
> 
> Ok I'm now running RSA without DST cert:
> # openssl crl2pkcs7 -nocrl -certfile 
> /etc/letsencrypt/live/clean-mailbox.com/fullchain.pem 
>  | openssl pkcs7 -print_certs -noout
> subject=CN = clean-mailbox.com 
> issuer=C = US, O = Let's Encrypt, CN = R3
> 
> subject=C = US, O = Let's Encrypt, CN = R3
> issuer=C = US, O = Internet Security Research Group, CN = ISRG Root X1
> 
> Still:
> 
> 2023-09-12T10:48:56.708719+02:00 mx2 postfix/smtpd[406672]: SSL_accept error 
> from m240-158.my-hammer.de [159.112.240.158]: 
> -1
> 2023-09-12T10:48:56.710166+02:00 mx2 postfix/smtpd[406672]: warning: TLS 
> library problem: error:0A000412:SSL routines::sslv3 alert bad 
> certificate:../ssl/record/rec_layer_s3.c:1586:SSL alert number 42:
> 
> Camille
> 
> Le 12/09/2023 à 10:15, Slavko via mailop a écrit :
>> Ahoj,
>> 
>> Dňa Tue, 12 Sep 2023 09:25:59 +0200 Geert Hendrickx via mailop
>>  napísal:
>> 
>>> The reason is likely the certificate itself, not the chain; this
>>> server offers (only) an ECC certificate, and while the vast majority
>>> of clients are compatible with this today, some still only support
>>> RSA.
>> Yes, i can confirm this. My MX's stats shows that one sender still
>> requires RSA. Unfortunately it is my bank, thus i use dual certs ;-)
>> 
>> In other words, the MX is only one my service with dual certs. When i
>> start to use EC, i had dual certs for MSA too, but after some time, i
>> abandon the RSA, as all clients was happy with EC...
>> 
>> regards
>> 
>> 
>> ___
>> mailop mailing list
>> mailop@mailop.org 
>> https://list.mailop.org/listinfo/mailop
> ___
> 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] Listed on Polspam.pl - how to delist?

['Ken O'Driscoll' via mailop]

If you believe that the Spamhaus DBL is referencing that RBL as a data
point, then you should raise the issue with them. There are Spamhaus people
on the mailop list.



Ken.



*From:* Sebastian Nielsen 
*Sent:* Monday, June 26, 2023 10:26 AM
*To:* 'Ken O'Driscoll' 
*Subject:* Sv: [mailop] Listed on Polspam.pl - how to delist?



Its that Spamhaus DBL ”reads” from polspam.pl so I get listed on spamhaus
regularly for being present in polspam. So its affecting deliverability to
many hosts that use Spamhaus DBL due to polspam “infecting” spamhaus.



*Från:* k...@odriscoll.eu  *För *Ken O'Driscoll
*Skickat:* den 26 juni 2023 11:22
*Till:* Sebastian Nielsen 
*Kopia:* Mailing List 
*Ämne:* RE: [mailop] Listed on Polspam.pl - how to delist?



If the listing is not causing you any problems, I’d suggest you ignore it.
There are loads of RBLs operated on a hobbyist/grudge basis which have zero
influence on deliverability.



If they are causing you problems and given that they have disabled
reasonable means of contact, then perhaps reach out to the recipient
organisation on a different channel to let them know that they have a
rogue/abandoned RBL in their filter stack.



Ken.



*From:* mailop  *On Behalf Of *Sebastian Nielsen
via mailop
*Sent:* Monday, June 26, 2023 9:39 AM
*To:* 'Mailing List' 
*Subject:* [mailop] Listed on Polspam.pl - how to delist?



It seems I have got listed on polspam.pl for some reason. I cannot find
why, if there is some email that I sent that triggered something, or if
someone accidentially pressed “Spam” instead of “Delete” which happens
regularly.

Theres no contact details on their website, and they have disabled their
contact form. And delisting mentions using this contact form.



Any idea how to get in contact with polspam.pl and have details of what for
spam that have been listed?
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Listed on Polspam.pl - how to delist?

[Ken O'Driscoll via mailop]

If the listing is not causing you any problems, I’d suggest you ignore it.
There are loads of RBLs operated on a hobbyist/grudge basis which have zero
influence on deliverability.



If they are causing you problems and given that they have disabled
reasonable means of contact, then perhaps reach out to the recipient
organisation on a different channel to let them know that they have a
rogue/abandoned RBL in their filter stack.



Ken.



*From:* mailop  *On Behalf Of *Sebastian Nielsen
via mailop
*Sent:* Monday, June 26, 2023 9:39 AM
*To:* 'Mailing List' 
*Subject:* [mailop] Listed on Polspam.pl - how to delist?



It seems I have got listed on polspam.pl for some reason. I cannot find
why, if there is some email that I sent that triggered something, or if
someone accidentially pressed “Spam” instead of “Delete” which happens
regularly.

Theres no contact details on their website, and they have disabled their
contact form. And delisting mentions using this contact form.



Any idea how to get in contact with polspam.pl and have details of what for
spam that have been listed?
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] software for a DMARC report db

[Ken O'Driscoll via mailop]

Take a look at parsedmarc (https://github.com/domainaware/parsedmarc). Out
of the box, you'll get them parsed into CSV. With integration, you can get
graphs via Splunk, Kibanna, etc.

It's not abandoned either.

Ken.

On Fri, Apr 7, 2023, 18:58 Michael W. Lucas via mailop 
wrote:

> Hi,
>
> I'm looking at setting up my own dmarc parser/aggregator db.
>
> Searches keep leading to dmarcts-report-parser and
> dmarcts-report-viewer. Is there a better option out there for
> self-hosting dmarc reports, or should I go ahead?
>
> (The projects don't look terribly active, so they're either complete
> or abandoned, and searches for competitors keep leading to commercial
> hosting.)
>
> Thanks for any hints,
> ==ml
>
>
> --
> Michael W. Lucashttps://mwl.io/
> author of: Absolute OpenBSD, SSH Mastery, git commit murder,
>  Absolute FreeBSD, Butterfly Stomp Waltz, Forever Falls, etc...
> ### New books: DNSSEC Mastery, Letters to ed(1), $ git sync murder ###
> ___
> 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] How should I interpret DMARC failure reports with "abuse reports"?

[Ken O'Driscoll via mailop]

The current DMARC RFC (7489) allows for a modified ARF format failure
report (see section 7.3.1).

If you don't want to receive them then remove the RUF from your DMARC RR.

I wouldn't treat them as complaints as that's not the intended purpose of
DMARC failure reports. DMARC reporting is for email  authentication status
and DMARC related message classification as a result of authentication
status.

Ken.

On Fri, Sep 23, 2022, 17:30 Leandro Santiago via mailop 
wrote:

> Hi list,
>
> I've been getting some DMARC failure reports when sending email through
> amazon ses and sparkpost direct to the `rua=` email [1]. I am not sure
> how I should interpret them, whether they really mean abuse reports due
> to SPAM or something else.
>
> For the context, DKIM, SPF and DMARC are properly configured. So far we
> don't have a DMARC policy, which might impact on those reports.
>
> The reports come from dmarc-report...@clouduss.com (a censornet
> product), but unfortunately I cannot post the whole content here, due to
> privacy reasons.
>
> They mention in their body [1] `this is an email abuse report`. They all
> have `Feedback-Type: auth-failure` instead of `Feedback-Type: abuse`,
> which is what I usually expect from such reports.
>
> Also, a few times they have `Delivery-Result: spam`, which seems to
> indicate they actually refer to some message sent by us marked as spam
> (which I assume is classified as a complaint), but most times they
> contain instead the header: `Delivery-Result: delivered`, which is
> confusing on how it should be different from `Delivery-Result: spam`.
>
> There seems to be little documentation about such headers online. So far
> the best I got is RFC-6591 [3], that states:
>
> delivered:  The message was delivered (not specific as to where).
>
> By "not specifying as to where", I can imagine that being spam is a
> possibility, but this is very ambiguous.
>
> So, here are my questions:
>
> - Should I handle those messages as spam complaints?
> - Should I handle the `Delivery-Result: delivered` the same way as
> `Delivery-Result: spam`?
>
> Other relevant headers:
>
> Identity-Alignment: dkim
> User-Agent: MimeKit
>
> Thank you in advance
>
> [1]:
>
> v=DMARC1; p=none; rua=mailto:postmas...@example.com;
> ruf=mailto:postmas...@example.com; fo=1;
>
> [2]:
> This is an email abuse report for an email message received from IP
> 1.2.3.4 on 2022-09-07 16:40:53. For more information about this format
> please see https://help.clouduss.com/dmarc-failure-reporting
> Below is some details information about this message:
> 1. SPF-authenticated Identifiers: pass
> 2. DKIM-authenticated Identifiers: pass
> 3. DMARC Mechanism check Result: pass
>
> [3]: https://www.rfc-editor.org/rfc/rfc6591#section-3.2.2
>
> --
> Regards,
>
> Leandro Santiago
> Software Craftsman at Lightmeter
> https://calendly.com/leandro-santiago
> https://getlightmeter.com
> ___
> 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] Delivery and DNS issues for Microsoft / m365

[Ken O'Driscoll via mailop]

They appear to know about it - there's an open incident (EX397744) on the 
service health dashboard. 

Ken.

> -Original Message-
> From: mailop  On Behalf Of Dan Malm via
> mailop
> Sent: Wednesday 6 July 2022 10:42
> To: mailop@mailop.org
> Subject: [mailop] Delivery and DNS issues for Microsoft / m365
> 
> Hi,
> 
> We're seeing a lot of DNS errors for *.mail.protection.outlook.com at
> the moment. NS lookup for mail.protection.outlook.com resolves to two
> hostnames that in turn resolve to the same IP. What IP they both
> resolves to varies over time, and one or more of those IPs doesn't
> respond at all on port 53, so whenever the non working IP is cached we
> can't lookup MX records for m365 customers for a while. The DNS servers
> we can reach also don't support edns or qname minimization...
> 
> And when DNS doesn't fail we have a lot of deliveries respond with:
> 
> Temporary server error. Please try again later ATTR2 [GV0CHE01FT017.eop-
> che01.prod.protection.outlook.com
> 
> I'm assuming we're not the only ones seeing these problems at the
> moment?
> 
> https://portal.office.com/servicestatus lists issues with outlook.com
> but the description there doesn't seem to fit what I'm seeing.
> 
> --
> BR/Mvh. Dan Malm, Systems Engineer, One.com
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Timeouts to Microsoft?

[Ken O'Driscoll via mailop]

They have two open incidents in their alert centre relating to access to 
Exchange Online and Microsoft 365.

As an EU based user, I can't say I've experienced anything, nor have any 
clients reported problems to me but most of them are only waking up now so...

Ken.

> -Original Message-
> From: mailop  On Behalf Of Stefano Bagnara
> via mailop
> Sent: Tuesday 21 June 2022 11:08
> To: mailop 
> Subject: [mailop] Timeouts to Microsoft?
> 
> Hi,
> 
> Since 4 hours we are experiencing slowness (e.g. connections timing out,
> very slow responses), to Microsoft both sending to their SMTP and
> reading via IMAP, from europe (checked from 4 different datacenters in
> europe).
> 
> Do you see the same?
> 
> --
> Stefano Bagnara
> Apache James/jDKIM/jSPF
> VOXmail/Mosaico.io/VoidLabs
> ___
> 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] Best practice for mailing list servers

[Ken O'Driscoll via mailop]

This is incorrect. The return-path is the address used by receiving the MTA to 
send bounce messages to when the recipient's 5322.From is unreachable for 
whatever reason.

So if your MLM sends a message to a non-existent address or there are some 
other delivery errors post-acceptance, then a bounce message will likely be 
sent to your 5321.from address, not the 5322.From.

Many mailbox providers do not reject during the SMTP conversation, but accept 
the message and generate a bounce later in their MTA chain. So it is important 
to monitor your 5321.from at all times.

This is true of all internet mail, not just MLM traffic.

Ken.


From: Axel Rau 
Sent: Wednesday, 15 June 2022, 19:18
To: Ken O'Driscoll 
Cc: mailop@mailop.org 
Subject: Re: [mailop] Best practice for mailing list servers



Am 15.06.2022 um 19:43 schrieb Ken O'Driscoll 
mailto:k...@wemonitoremail.com>>:

If your return-path is a CNAME, then you'll have problems with bounce 
processing too. Many MTAs will consider the return-path invalid when they can't 
find an MX RR; as will many message filters.
Their behaviour is wrong. As we all know, MX is only needed if I send mail to a 
domain.
The MLM is a host and needs no MX.

Return-path domains really need an MX record for mail to work properly.
Why?

Axel
---
PGP-Key: CDE74120  ☀  computing @ chaos claudius


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

Re: [mailop] Best practice for mailing list servers

[Ken O'Driscoll via mailop]

If your return-path is a CNAME, then you'll have problems with bounce 
processing too. Many MTAs will consider the return-path invalid when they can't 
find an MX RR; as will many message filters.

Return-path domains really need an MX record for mail to work properly.

Ken.


From: Axel Rau 
Sent: Wednesday, 15 June 2022, 16:36
To: Ken O'Driscoll 
Cc: mailop@mailop.org 
Subject: Re: [mailop] Best practice for mailing list servers



Am 14.06.2022 um 18:51 schrieb Ken O'Driscoll via mailop 
mailto:mailop@mailop.org>>:

* Make sure that the list's 5321.From (return-path/envelope/MAILFROM) domain 
has a valid and restrictive SPF
Domainpart of my return-path is a generic CNAME of a pair of MLMs
SPF requires a TXT RR which can’t coexist with a CNAME.

Too bad.
---
PGP-Key: CDE74120  ☀  computing @ chaos claudius


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

Re: [mailop] Best practice for mailing list servers

[Ken O'Driscoll via mailop]

Hi Taavi,

It really depends on what you are trying to achieve.

Depending on canalisation and what headers are being signed, there is no 
guarantee that a sender's DKIM won't be broken by the MLM. SPF alignment is 
already going to be broken. Also, not every DMARC user, for their own 
convoluted reasons, DKIM signs their messages. So, there is no guarantee that 
DMARC (with an enforcing policy) will survive an MLM. Rewriting the 5322.From 
is the safest option.

By always double signing, the MLM builds its own sending reputation. Many 
message filters already can distinguish mailing list traffic, signing with the 
list's keypair helps that. A list needs to have its own sending reputation. 
Depending on the message volume of the list, this may even allow a member with 
poor sending reputation to have their list posts reach the inbox.

Most MLM operators want to give the messages the best possible chance of being 
delivered to inboxes. Double DKIM signing and rewriting the 5322.From of DMARC 
enforced messages achieve this goal.

The other option is to rewrite every 5322.From address, optionally strip the 
sender's DKIM, and sign with a MLM keypair. I don't advocate this approach, but 
it achieves similar at a UX cost for some/many list users.

Assuming that senders with DMARC enforcing policies know what they are doing, 
or even have control over their domain/MTA etc., is a high risk and high 
maintenance gamble for MLM operators.

Unless you are a large mailbox provider, or have an academic interest in it, I 
wouldn't recommend low-volume senders spend time with ARC until it's fully 
baked.

Ken.

> -Original Message-
> From: mailop  On Behalf Of Taavi Eomäe via
> mailop
> Sent: Wednesday 15 June 2022 10:04
> To: mailop@mailop.org
> Subject: Re: [mailop] Best practice for mailing list servers
> 
> Hi,
> 
> just wondering, wouldn't it be significantly better to only modify
> headers and double-sign when the original message's DKIM signature
> doesn't pass? Absolutely correct me if I'm mistaken, but this would keep
> DMARC (if it also exists) valid and detach the mailing lists' reputation
> from the message, probably making deliverability better. If the senders
> have a proper setup.
> 
> ARC on top of that would be a nice clear indication that it has been
> forwarded in some way and DKIM would say it's not lying. The rest of the
> letters' senders can be rewritten.
> 
> 
> Or are SPF (hard)fails too strong of a negative signal in most cases
> that these DKIM-signed messages wouldn't be accepted?
> 
> 
> 
> 
> Taavi
> 
> On 14/06/2022 19:51, Ken O'Driscoll via mailop wrote:
> > Hi Axel,
> >
> > I would suggest:
> >
> > * Make sure that the list's 5321.From (return-path/envelope/MAILFROM)
> domain has a valid and restrictive SPF
> > * DKIM sign all list messages with your own key
> > * Use different DKIM keypairs for each list
> > * Don’t modify the originally message body (e.g., adding in a list
> footer etc.)
> > * If the sender's domain has DMARC with an enforcing policy
> (p=quarantine/reject) then rewrite the 5322.From to use the list's
> domain
> >
> > Not modifying the body of the message will give any original DKIM
> message signature the best chance of preserving validity.
> >
> > Signing with your own DKIM key will create an additional reputation
> data point for message filters, which will help over time.
> >
> > DMARC won't survive a MLM, so you have to rewrite the From to give the
> message a chance of being received. Your own DKIM signature will still
> be valid.
> >
> > Implementing ARC wouldn't hurt, but don't expect it to magically fix
> anything. Your ARC set still needs to be trusted by message filters
> which implement ARC and there is no centralised mechanism to facilitate
> this yet. Larger providers may use ML to trust particular ARC header
> sets but who knows.
> >
> > I wouldn't suggest that you implement DMARC on your list domain as it
> won't help with deliverability and will just cause more issues. It's not
> really designed for mailing lists.
> >
> > Ken.
> >
> >> -Original Message-
> >> From: mailop  On Behalf Of Axel Rau via
> >> mailop
> >> Sent: Tuesday 14 June 2022 16:51
> >> To: Paul Vixie via mailop 
> >> Subject: [mailop] Best practice for mailing list servers
> >>
> >> Hi all,
> >>
> >> I’m running a mailman3 site with several small mailing lists.
> >>
> >> Today Google let all mails without DKIM sig bounce.
> >> Other ESPs refuse my mails because of brokem DKIM sig.
> >>
> >> Currently the listserver does not DKIM-sign nor remove DKIM-sigs.
> >>
> &

Re: [mailop] Best practice for mailing list servers

[Ken O'Driscoll via mailop]

Hi Matthew,

The point of using different keypairs for different lists is that some message 
filters use the DKIM signing domain as a data point when calculating sender 
reputation.

Ideally, you want to have the signing domain match the From domain. If the 
lists use different From domains, then I'd recommend different keypairs for 
that reason.

If it's all using the same domain then the same keypair across all lists is 
probably fine.

If you really want to get into the weeds, different keypairs can help you 
isolatate and limit the reputational risk from DKIM replay attacks regardless 
of the same sending domain.

But, message volume also matters for building reputation and, there's no point 
in using separate keys for double digit per-list daily volumes. Combining under 
one key and one domain may also be a winning strategy in that case.

Ken.


From: mailop  on behalf of Matthew Richardson via 
mailop 
Sent: Tuesday, 14 June 2022, 19:30
To: mailop@mailop.org 
Subject: Re: [mailop] Best practice for mailing list servers

Ken O'Driscoll wrote:-

>* Use different DKIM keypairs for each list

Out of interest, why?

Are there any known issues with using the same keypair across multiple
lists, or indeed across multiple sending domains?

--
Best wishes,
Matthew
___
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] Best practice for mailing list servers

[Ken O'Driscoll via mailop]

Hi Slavo,

p=none is not always harmless. Some message filters treat p=none differently to 
not having DMARC. For example, Alice periodically treats p=none as equivalent 
to p=reject. Or there is an ISP who junks mail from domains with an RUA 
pointing to a freemail account, regardless of the policy. They are perhaps, 
rare, and extreme cases but there are more than a few providers that don't 
implement DMARC correctly and don't send reports either - messages just don't 
reach the inbox.

So, in this case, where I know absolutely zero about the poster's MLM audience 
etc., I recommend no DMARC record at all. It gives the best possible chance of 
the mailing list messages achieving inbox placement. Plus, most list operators 
don't have the time to be lecturing/mediating/pleading with ISPs who are 
blocking messages because don't understand DMARC. 

Of course, maybe the lists in question have a risk profile that would justify 
DMARC. If so, then it should be deployed fully, not just left lingering at 
p=none.

I do have a client where we implemented DMARC with p=reject on their lists. But 
they are not public lists, and the recipients belong to a very limited number 
of known domains.

Ken.

> -Original Message-
> From: mailop  On Behalf Of Slavko via mailop
> Sent: Tuesday 14 June 2022 18:08
> To: mailop@mailop.org
> Subject: Re: [mailop] Best practice for mailing list servers
> 
> Ahoj,
> 
> Dňa Tue, 14 Jun 2022 16:51:55 + Ken O'Driscoll via mailop
>  napísal:
> 
> > I wouldn't suggest that you implement DMARC on your list domain as it
> > won't help with deliverability and will just cause more issues. It's
> > not really designed for mailing lists.
> 
> Please, what issues will cause DMARC with policy None? Would not be
> better to suggest this instead of no DMARC?
> 
> regards
> 
> --
> Slavko
> https://www.slavino.sk
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Best practice for mailing list servers

[Ken O'Driscoll via mailop]

Hi Axel,

I would suggest:

* Make sure that the list's 5321.From (return-path/envelope/MAILFROM) domain 
has a valid and restrictive SPF 
* DKIM sign all list messages with your own key
* Use different DKIM keypairs for each list
* Don’t modify the originally message body (e.g., adding in a list footer etc.)
* If the sender's domain has DMARC with an enforcing policy 
(p=quarantine/reject) then rewrite the 5322.From to use the list's domain

Not modifying the body of the message will give any original DKIM message 
signature the best chance of preserving validity.

Signing with your own DKIM key will create an additional reputation data point 
for message filters, which will help over time.

DMARC won't survive a MLM, so you have to rewrite the From to give the message 
a chance of being received. Your own DKIM signature will still be valid.

Implementing ARC wouldn't hurt, but don't expect it to magically fix anything. 
Your ARC set still needs to be trusted by message filters which implement ARC 
and there is no centralised mechanism to facilitate this yet. Larger providers 
may use ML to trust particular ARC header sets but who knows.

I wouldn't suggest that you implement DMARC on your list domain as it won't 
help with deliverability and will just cause more issues. It's not really 
designed for mailing lists.

Ken.

> -Original Message-
> From: mailop  On Behalf Of Axel Rau via
> mailop
> Sent: Tuesday 14 June 2022 16:51
> To: Paul Vixie via mailop 
> Subject: [mailop] Best practice for mailing list servers
> 
> Hi all,
> 
> I’m running a mailman3 site with several small mailing lists.
> 
> Today Google let all mails without DKIM sig bounce.
> Other ESPs refuse my mails because of brokem DKIM sig.
> 
> Currently the listserver does not DKIM-sign nor remove DKIM-sigs.
> 
> It seems, that mails with DKIM-sig (from the author domain, but broken
> bei the list server) are accepted by Google.
> 
> Should I adopt ARC?
> Along with DMARC?
> 
> What is best practice in 2022?
> 
> 
> Any help appreciated,
> Axel
> ---
> PGP-Key: CDE74120  ☀  computing @ chaos claudius
> 
> ___
> 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] How "more secure" is actually less secure (regarding Gmail)

[Ken O'Driscoll via mailop]

The point of the measure is to reduce the chance of attacks related to password 
reuse.

If a reused password and the associated Gmail email address are exposed because 
of a security breach with Service X, then that data cannot be used by itself to 
access the associated Gmail account if 2FA is enabled and "less secure" MUA 
access prohibited. 

It has nothing to do with whether you trust your local storage.

Ken.

> -Original Message-
> From: mailop  On Behalf Of Jaroslaw Rafa via
> mailop
> Sent: Monday 30 May 2022 12:18
> To: mailop@mailop.org
> Subject: [mailop] How "more secure" is actually less secure (regarding
> Gmail)
> 
> Hello,
> today is the day when Google withdraws "access for less secure apps",
> which
> - translated to understandable terms ;) - means that IMAP client (or any
> other non-web app) cannot login to Google using password only. One has
> to switch either to use OAuth2 as the method of authentication (if the
> app supports it), or to "app passwords" (which are btw. available only
> if you have turned on 2FA on your account - I don't understand why
> Google does not offer "app passwords" feature for accounts without 2FA).
> 
> The wording "access for less secure apps" suggests that removing this
> feature makes the account more secure. In fact it's exactly the opposite
> - the account becomes less secure. Why?
> 
> Regardless whether I choose to use OAuth2 or "app passwords", it means
> storing the login credentials permanently in my IMAP client. For OAuth2
> the app asks *once* for authentication and then stores the access token.
> For "app passwords", as they are random 16-character strings impossible
> to remember, they also have to be stored in the app.
> 
> On the contrary, when I use password auth in my IMAP client I never,
> ever store the password in the app. I always type it manually when the
> app asks me. So the password is not stored anywhere on my computer, thus
> even when someone gets access to the computer, they can't access my
> email. With either
> OAuth2 or "app passwords" configured, once someone starts up the app,
> they have access to my email without need for any further
> authentication. Or someone can find the file where credentials are
> stored and use it to get access from their own app.
> 
> So which one is actually "more secure"??? :)
> 
> (Note: I don't use Gmail personally, but a few organizations I'm
> involved in use Gmail accounts which I have "inherited", so I have to
> use Gmail anyway for these organizations mail).
> --
> Regards,
>Jaroslaw Rafa
>r...@rafa.eu.org
> --
> "In a million years, when kids go to school, they're gonna know: once
> there was a Hushpuppy, and she lived with her daddy in the Bathtub."
> ___
> 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] Help with identifying invalid email domains

[Ken O'Driscoll via mailop]

Absolutely, if that’s why the question was being asked.

But even in that case, they still need to validate input during the COI process 
to reduce FPs when sending COI messages to domains with typos. A typo on the 
LHS means COI fails, which is the desired outcome. Plus, they can use other 
methods to reduce abuse of their COI process.

People should be validating email input fields as a matter of course.

Ken.

From: mailop  On Behalf Of Laura Atkins via mailop
Sent: Thursday 26 May 2022 10:42
To: mailop@mailop.org
Subject: Re: [mailop] Help with identifying invalid email domains

Given that DuckDuckGo is in the business of forwarding email, they MUST use 
confirmed opt-in to avoid having someone mistype an email address. It’s not 
just the domain part that’s in consideration here, they need to ensure that 
typos don’t happen on the left hand side as well. I’d argue that typos on the 
LHS to different are a bigger problem than the occasional hit to a spamtrap as 
they’re forwarding PII to the address.

laura




On 26 May 2022, at 10:21, Ken O'Driscoll via mailop 
mailto:mailop@mailop.org>> wrote:

Hi Omid,

If you are specifically looking to reduce domain related typos on user input, 
then you can use a project such 
asTypofinder<https://github.com/nccgroup/typofinder>. They also have a 
commercial offering.

Alternatively, you could also look at implementing an address validation 
services. Most will do the same thing (and more) but will already have it 
wrapped up in an API for you to call. Validation can be a sketchy industry, 
EmailHippo<https://www.emailhippo.com/> and Kickbox<https://kickbox.com/> are 
examples of two legitimate players.

Ken.

From: mailop mailto:mailop-boun...@mailop.org>> On 
Behalf Of Omid Majdi via mailop
Sent: Wednesday 25 May 2022 20:00
To: 
mailop_at_mailop.org_o...@duck.com<mailto:mailop_at_mailop.org_o...@duck.com> 
mailto:mailop@mailop.org>>
Subject: [mailop] Help with identifying invalid email domains

Hey all,

I'm looking to see if anyone has compiled any lists of invalid email domains? 
Examples of such would be typo domains and/or domains that accept all 
local-part addresses such as gmai.com<http://gmai.com/>, 
gmail.co<http://gmail.co/>, googlemai.com<http://googlemai.com/>, or 
proton.com<http://proton.com/>. If there's any resources someone could share 
for known invalid domains that would be incredibly helpful.

Thanks,
Omid Majdi
Product Lead
DuckDuckGo, Inc.
___
mailop mailing list
mailop@mailop.org<mailto:mailop@mailop.org>
https://list.mailop.org/listinfo/mailop

--
The Delivery Experts

Laura Atkins
Word to the Wise
la...@wordtothewise.com<mailto:la...@wordtothewise.com>

Email Delivery Blog: http://wordtothewise.com/blog





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

Re: [mailop] Help with identifying invalid email domains

[Ken O'Driscoll via mailop]

Hi Omid,

If you are specifically looking to reduce domain related typos on user input, 
then you can use a project such as 
Typofinder. They also have a commercial 
offering.

Alternatively, you could also look at implementing an address validation 
services. Most will do the same thing (and more) but will already have it 
wrapped up in an API for you to call. Validation can be a sketchy industry, 
EmailHippo and Kickbox are 
examples of two legitimate players.

Ken.

From: mailop  On Behalf Of Omid Majdi via mailop
Sent: Wednesday 25 May 2022 20:00
To: mailop_at_mailop.org_o...@duck.com 
Subject: [mailop] Help with identifying invalid email domains

Hey all,

I'm looking to see if anyone has compiled any lists of invalid email domains? 
Examples of such would be typo domains and/or domains that accept all 
local-part addresses such as gmai.com, gmail.co, googlemai.com, or proton.com. 
If there's any resources someone could share for known invalid domains that 
would be incredibly helpful.

Thanks,
Omid Majdi
Product Lead
DuckDuckGo, Inc.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] rejected by DMARC policy for microsoft.com

[Ken O'Driscoll via mailop]

You are the receiver, and you are choosing to reject messages that do not pass 
DMARC tests according to OpenDMARC.

So, I think that you are completely in control of whether you receive this 
message or not. Microsoft possibly sending a message which was not compliant 
with their published DMARC policy does not change that.

Also, my guess is that the SPF pass is just a pass, not an aligned SPF pass as 
per DMARC.

Ken.

> -Original Message-
> From: mailop  On Behalf Of Mary via mailop
> Sent: Monday 20 December 2021 16:38
> To: mailop@mailop.org
> Subject: [mailop] rejected by DMARC policy for microsoft.com
> 
> 
> Hello everyone,
> 
> I am trying to reply to an email that came from a domain hosted by
> outlook. My initial email was rejected:
> 
> [104.47.17.74]:25, delay=1.8, delays=1.4/0/0.24/0.19, dsn=5.7.511,
> status=bounced (host mail.protection.outlook.com[104.47.17.74] said: 550
> 5.7.511 Access denied, banned sender. To request removal from this list
> please forward this message to del...@messaging.microsoft.com. For more
> information please go to  http://go.microsoft.com/fwlink/?LinkId=526653.
> AS(1410) [DB8EUR05FT052.eop-eur05.prod.protection.outlook.com] (in reply
> to RCPT TO command))
> 
> Ok, so once I forward the bounced email to
> del...@messaging.microsoft.com, their automated reply fails with:
> 
> opendkim[660]: 5759E42DE2: external host mail-
> co1nam11hn2229.outbound.protection.outlook.com attempted to send as
> messaging.microsoft.com
> opendkim[660]: 5759E42DE2: key retrieval failed (s=selector2,
> d=messaging.microsoft.com):
> 'selector2._domainkey.messaging.microsoft.com' query failed
> opendmarc[611]: 5759E42DE2: SPF(helo): NAM11-CO1-
> obe.outbound.protection.outlook.com pass
> opendmarc[611]: 5759E42DE2: messaging.microsoft.com fail
> postfix/cleanup[138315]: 5759E42DE2: milter-reject: END-OF-MESSAGE from
> mail-co1nam11hn2229.outbound.protection.outlook.com[52.100.173.229]:
> 5.7.1 rejected by DMARC policy for microsoft.com;
> 
> 
> It appears that SPF is a pass, but OpenDMARC rejected the email.
> 
> Does this look like a microsoft problem or is it me?
> 
> Thank you.
> ___
> 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] Locally hosted anti-spam solution recommendations?

[Ken O'Driscoll via mailop]

Hi Otto,

For frontends, and if you don't mind a bit of hacking, take a look at MailCow 
(https://mailcow.email/) and Modoboa(https://modoboa.org/en/). They will sit in 
front of an open-source mail application stack and provide quarantine and 
allow-list control for end users.

For on-premise all-in-one solutions, look at Zimbra (https://www.zimbra.com/) 
or Open-Xchange (https://www.open-xchange.com/). 

I have no personal experience of any of these, they were all potential 
solutions a client was testing a while ago. Their business case was different 
to your one, but similar situation with current vendor EOL. 

And I'm assuming you want open-source. If you don't, there a plenty of fine 
filtering appliances that have user-level control.

Ken.

> -Original Message-
> From: mailop  On Behalf Of Otto J. Makela via
> mailop
> Sent: Wednesday 20 October 2021 14:49
> To: mailop@mailop.org
> Subject: [mailop] Locally hosted anti-spam solution recommendations?
> 
> We're currently running Roaring Penguin CanIT as our mail frontend, and
> have been given an end-of-life notice from the new owners:
> https://go.zixcorp.com/index.php/email/emailWebview?md_id=21715
> 
> So, now we're looking for a good frontend with antispam functions.
> 
> CanIT is a set of open source software (Sendmail, Spamassassin,
> blocklists, ClamAV, opendkim etc) packaged with a nice web gui interface
> to control it all on a locally hosted Linux server.
> 
> And that's basically what we'd also need to replace it.
> 
> Some random cloud hosting spam solution is not a viable option, we're a
> Finnish government owned contractor. Also we need to know (if need be)
> what happened to each and every email coming and going, not "perhaps our
> proprietary spam system ate it, we won't tell you"
> as so many of these cloud solutions seem to be.
> 
> Any recommendations?
> 
> --
>/* * * Otto J. Makela  * * * * * * * * * */
>   /* Phone: +358 40 765 5772, ICBM: N 60 10' E 24 55' */
>  /* Mail: Mechelininkatu 26 B 27,  FI-00100 Helsinki */
> /* * * Computers Rule 0100 01001011 * * * * * * */
> ___
> 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] Paging the Yahoo! postmaster

[Ken O'Driscoll via mailop]

Hi Matt,

They know how to open cases, and have done, and have incident numbers etc. 
That’s not the issue.

The problem is the non-response to the cases they have open with regard to this 
one IP. They open cases all the time without issue. I think there’s some quirk 
here that requires manual intervention. And, since I’m not a fan of emailing 
people directly, hence my post here.

Ken.

From: Matt Vernhout 
Sent: Thursday 23 September 2021 14:38
To: Ken O'Driscoll 
Cc: mailop 
Subject: Re: [mailop] Paging the Yahoo! postmaster

Ken,

Check out https://postmaster.yahooinc.com/ for help - there is a contact form 
and an email address you can reach out to for help directly from the Yahoo team.

Cheers,

~ Matt Vernhout

http://www.emailkarma.net
Twitter: @emailkarma/@CAUCE


On Thu, Sep 23, 2021 at 9:26 AM Ken O'Driscoll via mailop 
mailto:mailop@mailop.org>> wrote:
Hi there,

I have an ESP client that appears to be stuck in an stock reply loop with a 
particular postmaster issue. The issue relates to 421’ing on a specific IP, 
which is used by a single sender for transactional messages. They have been 
trying to get this looked at for nearly a month, and I’m suspecting that their 
case is being misclassified or something like that.

Would very much appreciate someone reaching out off-list.

Thanks,

Ken.

___
mailop mailing list
mailop@mailop.org<mailto:mailop@mailop.org>
https://list.mailop.org/listinfo/mailop
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Paging the Yahoo! postmaster

[Ken O'Driscoll via mailop]

Hi there,

I have an ESP client that appears to be stuck in an stock reply loop with a 
particular postmaster issue. The issue relates to 421'ing on a specific IP, 
which is used by a single sender for transactional messages. They have been 
trying to get this looked at for nearly a month, and I'm suspecting that their 
case is being misclassified or something like that.

Would very much appreciate someone reaching out off-list.

Thanks,

Ken.

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

Re: [mailop] Gmail putting messages to spam

[Ken O'Driscoll via mailop]

The PSL does not assert that listed TLDs are real (accredited) or not, merely 
that they should be treated as such for evaluation purposes.

eu.org is just a regular domain which has an expiry date. If the registrant 
fails to pay the bill, the registration will lapse and the DNS objects (along 
with all of the entries/sub-domains) will disappear. It's only treated slightly 
differently, similar to eu.com, because of the historic volume of sub-domains 
used by legitimate corporate senders. This legacy is because they predate the 
official .eu ccTLD so they used to be the only way to have a pan-European 
domain name.

These days, there are very few companies using these sub-domains as sending 
domains. They are an anomaly. I have seen deliverability problems connected 
with them in the recent past and I'd advise any sender to avoid them.

Ken.


From: mailop  on behalf of Mark Milhollan via mailop 

Sent: Monday 20 September 2021, 19:02
To: mailop
Subject: Re: [mailop] Gmail putting messages to spam

On Mon, 20 Sep 2021, Ken O'Driscoll wrote:

> 2. Your sending domain (rafa.eu.org) is a sub-domain of a pseudo-TLD which a) 
> gives sub-domains away for free, and b) has an overly permissive SPF policy 
> ("v=spf1 +all"). The reputation of your sub-domain is going to be influenced 
> by the reputations of the base domain and all of the other sub-domains.

One would hope Gmail consults the PSL which would disclose that
rafa.eu.org is not merely/only a subdomain of (name under) eu.org but
rather it is its own apex domain, just as names under com and co.uk are,
i.e., milhollan.com is a zone/parent delegated from com not merely a
name under com.  And I certainly hope I don't inherit the reputation of
com and all the names under it.

 $ psl --print-reg-domain com milhollan.com co.uk eu.org rafa.eu.org
 com: (null)
 milhollan.com: milhollan.com
 co.uk: (null)
 eu.org: (null)
 rafa.eu.org: rafa.eu.org

I'll agree that if obtaining eu.org domains is too easy that might be
too strong a negative signal to easily overcome, or put another way it
might be easy to include other things that make a decision of spam for
only some of a series of messages.


/mark
___
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] Gmail putting messages to spam

[Ken O'Driscoll via mailop]

Two observations:

1. Your SPF record ("v=spf1 a mx ?all") is not optimal. While technically 
correct, the neutral qualifier ("?") isn't a great signal these days. I would 
suggest you use the softfail (~) qualifier for the default policy, e.g. "v=spf1 
a mx ~all". It is best current practice to make an assertation that you don't 
approve of non-listed senders.

2. Your sending domain (rafa.eu.org) is a sub-domain of a pseudo-TLD which a) 
gives sub-domains away for free, and b) has an overly permissive SPF policy 
("v=spf1 +all"). The reputation of your sub-domain is going to be influenced by 
the reputations of the base domain and all of the other sub-domains. 

While I understand the legitimate frustrations that some of the providers' ML 
algorithms struggle with legitimate micro-senders, I think your specific 
problems are (in part at least) connected with your sub-domain.

I would suggest that you great a real domain, DKIM sign with that domain, have 
a responsible SPF record, and as was suggested previously on this list, send 
DMARC aggregate reports to increase your sending footprint.

Ken.

> -Original Message-
> From: mailop  On Behalf Of Jaroslaw Rafa via
> mailop
> Sent: Monday 20 September 2021 13:17
> To: mailop@mailop.org
> Subject: [mailop] Gmail putting messages to spam
> 
> I want to return to an old issue, which repeatedly happens again and
> again, that is, Google putting emails from me to recipient's spam
> folder. What's absurd, this happens not only to Gmail addresses to which
> I am writing for the first time, but also to recipients with whom I have
> previously corresponded and who marked my messages as non-spam. It even
> happens when I'm replying to a message I got from a Gmail user, which is
> totally absurd!
> It can even happen in a middle of an email exchange - ie. I have once
> exchanged a few messages with a Gmail user without problems, then
> suddenly one of my subsequent messages in the conversation went to Spam.
> 
> This is really annoying and makes me mad. Can't Google really do
> anything about this? I have NEVER, EVER sent any spam from this address.
> I am NOT a bulk sender at all - I send only purely personal messages,
> and there are very few of them. I don't send on behalf of any third
> parties. SPF, DKIM, DMARC, rDNS is all correct - I sent a few test
> messages to test Gmail accounts I have created and Google displays
> everything as "PASS".
> 
> There is absolutely no reason to classify me as a spammer. And it seems
> that this classification is based purely on my sender address or domain,
> because when I send from the same server, from the same IP address
> messages with sender address from a different domain, they arrive to
> Inbox without issues. So it's not a matter of "bad" IP reputation. It's
> a matter of my particular address/domain. Why Google dislikes it so
> much?
> 
> I am even afraid to send anything to mailing list like this, because
> many recipients here may be on Gmail, and when they receive my message
> it will go to their Spam folders and they won't see it, so Google's AI
> will have even stronger signal that I'm a "spammer" and put more of my
> messages to spam...
> Seems to be a hopeless loop, is there any way out of this?
> --
> Regards,
>Jaroslaw Rafa
>r...@rafa.eu.org
> --
> "In a million years, when kids go to school, they're gonna know: once
> there was a Hushpuppy, and she lived with her daddy in the Bathtub."
> ___
> 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] Blocked by gmail

[Ken O'Driscoll via mailop]

You may contact Google using this form: 
https://support.google.com/mail/contact/bulk_send_new They won’t reply directly 
to you but if the problem is genuinely on their end, they will fix it within a 
few weeks.

However, I think that the problem you are experiencing is related to either the 
general quality of your mail-stream, the reputation of the sending IP 
addresses, or a specific element within the message for this one customer.

I would suggest that you closely review the type of messages going out and the 
URLs in those messages.

Ken.

From: mailop  On Behalf Of Jan Ackerstaff via mailop
Sent: Wednesday 14 July 2021 08:10
To: mailop@mailop.org
Subject: [mailop] Blocked by gmail

Hello there,

we're a small data center and hosting company with some customers that are 
sending mails over our smtp relay.
Since some days we're facing a problem with gmail recipients.
Our system has detected that this message is
421-4.7.0 suspicious due to the nature of the content and/or the links within.
421-4.7.0 To best protect our users from spam, the message has been blocked.
421-4.7.0 Please visit
421 4.7.0  https://support.google.com/mail/answer/188131 for more information

We had no problems last weeks with hacked mail accounts or spam.
The send mails are 100% legit from a fairly large company, the mails are 
requested on the part of the customer (order confirmations).
Since we get the same warning from other customers too, there is no common 
ground in the mail content.

Is there any possibility to get contact to a person?

Beste Grüsse / Kind Regards

Jan Ackerstaff
Fachinformatiker Systemintegration | Infrastruktur Services

OMG.DE GmbH
Kornkamp 40
26605 Aurich

TEL: 0 49 41 / 60 44 5 -
MAIL: jan.ackerst...@omg.de

Diese eMail enthält vertrauliche und rechtlich geschützte Informationen, die 
ausschließlich für den vorgesehenen Adressaten bestimmt sind. Sollten Sie nicht 
der vorgesehene Adressat dieser eMail oder dessen Vertreter sein, so beachten 
Sie bitte, dass jede Form der Kenntnisnahme, Speicherung oder Weitergabe des 
Inhalts dieser eMail unzulässig ist. Wir bitten Sie, in diesem Fall den 
Absender zu informieren und die eMail mit sämtlichen Anlagen dauerhaft zu 
löschen.

Bitte denken Sie an unsere Umwelt, bevor Sie diese eMail ausdrucken!

Hier erhalten Sie direkten Zugriff auf unser Support-Ticket-System: 
https://otrs.omg.de/otrs/customer.pl

[cid:image001.png@01D77899.03D2E040][cid:image002.png@01D77899.03D2E040][cid:image003.png@01D77899.03D2E040][cid:image002.png@01D77899.03D2E040][cid:image004.png@01D77899.03D2E040]



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

Re: [mailop] mail.ru broke mailing lists

[Ken O'Driscoll via mailop]

My understanding is that they don't accept unauthenticated messages, not just 
limited to a DMARC policy.

So, if your mailing list is sending messages with yandex.ru in the 5322.From 
(visible From) address but the messages are not DKIM signed using yandex.ru as 
the signing domain and the 5321.From (return-path / envelope) address is 
different, then they look like spoofing and will be rejected.

This is not an uncommon mail filter configuration these days. Mailing lists are 
not accommodated by mailbox providers in the same way as they were in the past.

My guess is that the solution is to have your mailing list software (groups.io) 
use the mailing list address in the 5322.From (like how this list works) and 
DKIM sign the outbound messages using the list's domain.

Ken.

> -Original Message-
> From: mailop  On Behalf Of Lena--- via mailop
> Sent: Monday 12 July 2021 10:23
> To: mailop@mailop.org
> Subject: [mailop] mail.ru broke mailing lists
> 
> According to Юлия П. in Abuse Team Mail.ru,
> they'll not change their new unannounced policy:
> messages from mailing lists (at groups.io) from authors @yandex.ru
> are rejected by mail.ru though DMARC for yandex.ru is p=none.
> 
> Thus, mail.ru became unusable for all people who participate
> in discussion mailing lists.
> 
> Below my futile attempts to explain (bottom-quoting required by them).
> 
> =
> 
> Subject: Re: [Ticket#2021071021014077] Мои письма воспринимаются как
> спам
> Date: Mon, 12 Jul 2021 11:54:08 +0300
> To: l...@lena.kiev.ua
> From: "ab...@corp.mail.ru" 
> 
> Здравствуйте.
> 
> Ответ о причине блокировке был дан ранее, каждый почтовый провайдер в
> праве
> использовать собственные метрики для своей антиспам-системы.
> Блокировка писем, которые поступают без авторизации на соответствующих
> серверах, не будет снята, эта логика не может быть изменена.
> 
> --
> С уважением,
> Юлия П.
> Abuse Team Mail.ru
> 
> 
> > У домена yandex.ru политика DMARC "p=none", именно чтобы не ломать
> > mailing lists. Поэтому в данном случае mail.ru не имеет права
> > отвергать письма по поводу DMARC.
> >
> > mail.ru имел бы право отвергать письма, если бы yandex.ru написал
> > "p=reject".
> > Но yandex этого не сделал. Преднамеренно, чтобы discussion mailing
> lists
> > могли продолжать работать.
> >
> > Я надеюсь, что сегодня на смене поддержки mail.ru более компетентный
> > работник.
> >
> > ~ $ dig +short _dmarc.yandex.ru txt
> > "v=DMARC1; p=none; fo=1;
> > rua=mailto:dmarc_...@auth.returnpath.net,mailto:dmarc-...@yandex.ru;
> > ruf=mailto:dmarc_a...@auth.returnpath.net;
> > ~ $
> >
> > > Повторимся, SPF в ваших письмах действительно проходят проверку, но
> из-за
> > > того, что From и envelope-from не совпадают, такие письма технически
> > > считаются подставными по отношению к домену, указанному во From -
> адресу
> > > видимому получателю, по аналогии с действием политики DMARC:
> > > https://tools.ietf.org/html/rfc7489
> > >
> > > Для решения вопроса вы можете использовать иную систему, используя
> адрес в
> > > собственном домене в качестве отправителя, а не сохраняя/подставляя
> адрес
> > > клиента. В таком случае письма успешно пройдут спам-фильтры.
> > >
> > > --
> > > С уважением,
> > > Юлия П.
> > > Abuse Team Mail.ru
> > >
> > >
> > > > Вы не понимаете, как работают SPF и discussion mailing list.
> > > > Вы наверно даже никогда не пользовались ими.
> > > > Участники конференции отправляют письма на адрес конференции
> > > > (в данном случае tg...@groups.io), сервер конференций
> > > > рассылает копии всем участникам конференции. В строке заголовка
> "From:"
> > > > сохраняется (не подставляется, а сохраняется!) адрес автора письма
> > > > (в данном случае @yandex.ru),
> > > > а в envelope-from (Return-Path) сервер конференций указывает адрес
> > > > @groups.io .
> > > > Это не я придумала, listserver-ы используются с 1984 года.
> > > > Проверка SPF должна быть по envelope-from, а не "From:".
> > > > Вы не понимаете, что такое envelope-from.
> > > > Вы жмете на первую попавшуюся кнопку, не понимая сути проблемы.
> > > > Пожалуйста, передайте эту переписку специалистам.
> > > >
> > > > > Мы понимаем, как работает SPF и для какого домена она
> проверяется. Суть не
> > > > > в невалидности SPF самой по себе, а в том, что фактически письма
> > > > > отправляются с одних серверов, а в качестве отправителя
> подставляется
> > > > > совершенно иной домен mailbox-провайдера. Если вы не можете
> обеспечить
> > > > > авторизацию непосредственно для yandex.ru, отправляя письма
> якобы с него,
> > > > > рекомендуем использовать соответствующий вашему собственному
> домену From.
> > > > >
> > > > > --
> > > > > С уважением,
> > > > > Юлия П.
> > > > > Abuse Team Mail.ru
> > > > >
> > > > >
> > > > > > Работник support-а Юлия П. не читает, тыкает на кнопки куда
> попадя.
> > > > > >
> > > > > > > Письмо, по вопросу блокировки которого вы обратились, было
> отправлено с
> > > > > > > yandex.ru без авторизации на их серверах (не прошло проверку

[mailop] Issues with Google Postmaster Tools

[Ken O'Driscoll via mailop]

I'm seeing previously verified domains revert to "Not Verified" along with 
previously removed domains being re-added to the dashboard as verified. Others 
are reporting similar on another channel.

Interested how widespread this is and has anybody heard anything useful from 
Google?

And yes, I know it's a free service. I'm perfectly fine if GPT breaks but I 
don't want my email address showing up as a new domain owner on the search 
consoles of former clients for obvious reasons.

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

Re: [mailop] GMail DKIM support for ed25519-sha256

[Ken O'Driscoll via mailop]

Hi Odhiambo,

Dual DKIM signing is simply means signing a message with more than one DKIM 
key. The specification allows for this and it is pretty common. For example, 
ESPs typically double sign messages, one signature asso ciated with their 
own domain, and one associated with the sender’s (their client’s) domain.

Section 4 of the specification (RFC 6376) 
talks more about multiple signatures in case you want further reading.

Ken.

From: mailop  On Behalf Of Odhiambo Washington via 
mailop
Sent: Thursday 15 April 2021 08:59
To: Stuart Henderson 
Cc: Wolfgang Rosenauer ; mailop@mailop.org
Subject: Re: [mailop] GMail DKIM support for ed25519-sha256



On Tue, Apr 13, 2021 at 6:44 PM Stuart Henderson via mailop 
mailto:mailop@mailop.org>> wrote:
On 2021/04/13 11:11, Wolfgang Rosenauer via mailop wrote:
> Hi,
>
> I'm seeing issues with GMail not recognizing a valid DKIM signature.
>
> Message is correctly signed like:
> DKIM-Signature: v=1; a=ed25519-sha256;
>
> GMail reports
> dkim=neutral (no key)
>
> while most DKIM validators (incl. dmarcian) are totally fine with the
> provided key.
> The only reason I could imagine is the key/hash format but I haven't seen
> any official documentation from GMail if ed25519-sha256 is supported or not.
>
> Any ideas or recommendations?

I don't know specifically about gmail, but generally support for ed25519
in DKIM is still a bit lacking, I think the advice for this is still to
dual-sign.

How does dual-signing work? Sorry to sound so ignorant, but I am only hearing 
about dual-signing for the first time.

--
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
"Oh, the cruft.", grep ^[^#] :-)
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Reliability of DMARC reports?

[Ken O'Driscoll via mailop]

> -Original Message-
> From: mailop  On Behalf Of Hans-Martin Mosner
> via mailop
> Sent: Sunday 14 March 2021 07:43
> To: mailop 
> Subject: [mailop] Reliability of DMARC reports?
> 
> Hello,
> 
> due to the recent GMX mail rejection incident (for which I still don't
> have a satisfactory explanation from GMX) I've enabled DMARC on our mail
> server in the hopes of getting better deliverability.

DMARC does not improve deliverability. However, the discipline that it enforces 
with maintaining SPF and DKIM alignment can help with deliverability as you are 
clearly identifying your mail stream, particularly for high volume senders. In 
fact, DMARC with an enforcing policy may cause some previously legitimate 
messages to be rejected. DMARC is intended to prevent unauthorised use of a 
domain in the 5322.from header, nothing else.

> But some of our outgoing mails were rejected, and the aggregate DMARC
> reports we were getting weren't too helpful (again :-( )
> 

Why? The aggregate reports should provide enough information on why a DMARC 
evaluation might be failing.

> Since this is a completely new area for me, I'm trying to make sense of
> the report content, and of course I'm trying to adjust our DNS records
> to limit damage.
> 
> As far as I understand, the report contains a copy of our published
> policy as well as records per sending IP. In the report I'm just looking
> at, it's stated that our domain and subdomain policy is "reject"
> although I changed it to "quarantine" within the same DNS update in
> which I changed the rua address from a generic one to a special receiver
> address, so I know the reporter must have read the new version of the
> DMARC DNS record because they sent to that special address.

That may be an incorrect assumption. The RUA address could have been re-read 
prior to sending the report, but the report will have contained data based on 
the historic DMARC policy. Each report contains a record of the p= and sp= at 
the time the messages were evaluated, not the time it was sent. Look at the 
time period on the report.

> The report also claims that SPF failed, although our SPF record included
> the outgoing mailserver from the beginning, of course.

For diagnosing SPF issues, the report will tell you the source IP address, the 
envelope (5321.from) address, how the SPF domain was derived (envelope or 
helo), the results of the receiver's (report sender) SPF test, and the SPF 
alignment according to DMARC.

Typically, SPF fails alignment because the recipient MTA forwards the message 
to a DMARC aware final hop MTA which now see a different source IP. This is 
pretty common, in particular when a recipient gets their hosting provider to 
forward their vanity domain's email on to their freemail account.

So it should be pretty easy to determine why SPF failed.

> So this report looks like a red herring to me - not enough information
> to debug what may have been wrong (ok for an aggregate report) but also
> containing highly questionable data.

Why specifically do claim that the data is questionable? If you wish, please 
share the un-redacted report with me off-list so that I may better understand 
your claim.

> I'm about to switch off DMARC off again or at least change the policy to
> "none" as it seems to hurt more than help.

I think this is a very good idea. Nobody should run DMARC with an enforcing 
policy until they fully understand their mail flow and how DMARC could effect 
it. This is specifically what "none" is intended for.

> What's your experience with reliability of DMARC reports? Mostly
> helpful? Too much nonsense?

I have never experienced a problem with the reliability of DMARC aggregate 
reports, and I look at them for a living.

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

Re: [mailop] How important is an ipv6 ptr record?

[Ken O'Driscoll via mailop]

[Added mailop as CC.]

On Thursday 11 February 2021 16:34, Dave Crocker wrote:
> A basic issue I've tried to raise but finally gave up on is that email
> relaying means that a message can start in a v4 environment and then
> transit a v6 one.  The Originator has no control over that.
> 
> So differential rules for v6 and v4 doesn't actually make sense, unless
> the receiving server can tell whether the message has gone more than one
> hop...

Or the receiver (final hop or not) has different technical capabilities for 
filtering IPv6 and IPv4 message sources. For example, RBL operators haven't 
(yet?) scaled to mapping bad IPv6 space to the same level as IPv4 space. This 
means that (as Alex already noted) domain reputation may come into play more 
than with IPv4 sources, particularly for smaller sites.

Until technical parity exists between how each space is evaluated, they'll be 
treated differently.

Ken.

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

Re: [mailop] How important is an ipv6 ptr record?

[Ken O'Driscoll via mailop]

 
> The much larger address space makes it too easy for a bad actor to jump
> around and, therefore, not develop a bad reputation associated with the
> address.  So non-history features are made more strict.

This would be my impression too.

But jumping around on the same provider is the also a thing. With the abundance 
of available address space, low-cost hosting/VPS providers can assign far more 
IPv6 IPs at little cost or concern. The traditional (IPv4) model of even a 
low-cost provider having to care about the quality of their customer IP space 
is gone. This means that spam operations don't get disrupted when the IP gets 
blocked.

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

Re: [mailop] How important is an ipv6 ptr record?

[Ken O'Driscoll via mailop]

> Do people care about them if there is an appropriate SPF record in
> place?

IPv6 space is considered low quality from an email perspective, so the answer 
is yes, receivers are likely to care about missing rDNS.

Receivers will care as much if not more that IPv4 if anything is out of place 
with mail from an IPv6.

If you're sending from a IPv6 address, make sure all of your ducks are in a 
line. That means an SPF that don't list too many ranges, DKIM signing using the 
5322.From domain and FCrDNS on your SMTP server.

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

Re: [mailop] [External] Re: How to do Outbound Relay from M365 previously O365

[Ken O'Driscoll via mailop]

You can configure the connector to only relay messages to your MTA if its (CA 
issued) cert's CN matches something specific. However, as you note, you also 
need to trust their Exchange Online IP range too. Now those IPs are not the 
same as their Azure allocations so the risk is the entire Exchange Online 
platform being compromised and your MTA specifically targeted, as opposed to a 
malicious user on a free Azure trial specifically targeting your MTA.

Incidentally, the feature you're looking for (basic authentication for smart 
hosts) exists in on-premise Exchange. I assumed it existed with the on-line 
edition too but it does not appear to, at least, any more.

Ken.

From: mailop  On Behalf Of Kevin A. McGrail via 
mailop
Sent: Friday 18 September 2020 15:50
To: mailop@mailop.org
Subject: Re: [mailop] [External] Re: How to do Outbound Relay from M365 
previously O365

On 9/18/2020 10:18 AM, Ken O'Driscoll via mailop wrote:
You need to set up mail flow connectors in Exchange Online. Authentication is 
certificate and/or IP based.

I think this explains it fairly well:
https://docs.microsoft.com/en-us/exchange/mail-flow-best-practices/use-connectors-to-configure-mail-flow/set-up-connectors-to-route-mail


Thanks, but for outbound FROM m365 to the internet through a smarthost, this 
wouldn't suffice.  We couldn't accept Microsoft's Cert or all of Microsoft's 
IPs for relay without significant risk of inevitable abuse.

I don't think I'm missing something on this but completely open to the fact 
that I might be.

Regards,

KAM
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] How to do Outbound Relay from M365 previously O365

[Ken O'Driscoll via mailop]

You need to set up mail flow connectors in Exchange Online. Authentication is 
certificate and/or IP based.

I think this explains it fairly well:
https://docs.microsoft.com/en-us/exchange/mail-flow-best-practices/use-connectors-to-configure-mail-flow/set-up-connectors-to-route-mail

Ken.


From: mailop  on behalf of Kevin A. McGrail via 
mailop 
Sent: Friday, 18 September 2020, 14:15
To: mailop
Subject: [mailop] How to do Outbound Relay from M365 previously O365

Hello Mailoppers,

I might have asked this before but I've been going round and round with
Microsoft tech support on SMTP basics.  Microsoft has, no joke, been
working on answer this questions since June 30th.  It's been a very bad
shotgun approach of sending random knowledge bases, doing screenshares,
watching their interface crash, etc.

For years, we used to relay mail from m365 through our on-premise
Linux-based SMTP server using basic plain SMTP AUTH.  At some point,
they removed it but can't say when.  They really have no record it ever
worked other than the fact that we have the relay in place on some
accounts that back in June stopped working.

Does anyone know what authentication methods might work with m365?  Ever
seen a KB or anything about it?  I am sad to say they are recommending
things like allowing all of their IP range to relay and the very nice
tech who is helping is just too junior to understand how bad an idea
that is.

Regards,

KAM


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] MTA Server IP "Warm Up" Reputation Recommended Best Practices

[Ken O'Driscoll via mailop]

I have a client in the same niche corporate/commercial non-bulk space and the 
exact process they use to "warm up" new IPs is to introduce them into their 
existing mail flow along with the existing seasoned outbound IPs. They don't 
have any "cold" IP space, every IP (even the ones reserved for 
redundancy/future use) is cycled into the outbound email stream every 1-2 weeks 
for a few days. This process has worked for over 10 years. Obviously, you need 
the right infrastructure for that.

Ken.


From: mailop  on behalf of L. Mark Stone via mailop 

Sent: 03 September 2020 20:02
To: mailop 
Subject: Re: [mailop] MTA Server IP "Warm Up" Reputation Recommended Best 
Practices

Thanks Laura and Chris for your replies, and sorry if I wasn't as precise in my 
language as perhaps I should have been. I've been in the email business since 
2005 and have been impressed with the general high experience level of the 
posters on this list. I didn't think I needed to be as specific as I think you 
wanted me to be -- especially because I was asking for guidance regarding an 
optimal MTA IP "warm up" process, and just using my case as an example of what 
happens when that process (if one exists) is not apparently followed.

1) So to be clear, none of my nor my customers' domains are on blocklists 
presently (nor were they at the time ~2 months ago), nor were/are any of my 
MTA's IPs on any public block lists.

2) The IP address of the new MTA we attempted to put into limited production 
was placed on the internal block lists of Microsoft, Google and Mimecast (which 
I resell) the same weekend we put that new MTA into limited production. Test 
emails we had sent prior to the production weekend to those and other service 
providers all sailed through OK. The outbound email we fed through the new MTA 
that weekend was a simply portion of the normal outbound email we process 
through our existing MTAs.  All of the email processed through our existing 
MTAs that weekend was delivered successfully.

3) Microsoft's response was that this IP was not eligible for remediation.  I 
presumed, since none of the bounce messages in the logs indicated anything 
regarding email contents, nor anything related to the sending domains, that 
this was due to the IP being "new".

So that was why I titled this thread "MTA Server IP "Warm Up" Reputation 
Recommended Best Practices".

We have other IPs we can use if needed, so again, I am less concerned about 
improving this IP's reputation than I am with not repeating this outcome.

No one has yet indicated a better process for warming up an IP than essentially 
"send some email" -- that's not something we can do with our customers' 
production email flows.  So if we need first to set up a separate domain or 
two, and open a raft of Yahoo, Gmail and Outlook.com accounts as destinations 
to create a reputation for an IP where we can afford to have these emails 
blocked, and; then deal with any bounce messages etc., OK.  That process 
seems... sub-optimal at best.

If anyone has a better process for warming up sending MTA IPs, I would be 
grateful.

With best regards to all,
Mark
___
L. Mark Stone, Founder
Mission Critical Email LLC

- Original Message -
From: "mailop" 
To: "mailop" 
Sent: Thursday, September 3, 2020 1:31:03 PM
Subject: Re: [mailop] MTA Server IP "Warm Up" Reputation Recommended Best 
Practices

On 2020-09-03 10:41, Laura Atkins via mailop wrote:

> What “other block lists” are you on? Knowing that may help identify what
> you did wrong. It’s unusual for IPs to be blocked outright after 3 days
> of mail. What were you sending and to whom were you sending it? Who owns
> the IP? Where is it routed from? How did you acquire the IP address? Is
> it being routed?



> This is one of those questions that’s very difficult to actually answer
> in the hypothetical.

Precisely.  We've seen this scenario many times before, new sending IP,
and seems to get listed right away even tho the volumes are kept low at
first.  By not paying attention/investigating other listings, you might
not notice the fact that you made a glaring configuration error that
spells "infected!" to not just DNSBLs, but generalized inbox
filtering as well.  But the person thinks it's to do with "new IP",
rather than "new IP with obvious problems".

We see it all the time, and it's impossible to answer in the hypothetical.

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Hotmail.tld DMARC record issue

[Ken O'Driscoll via mailop]

Well, whoever’s responsible for the change control process that allowed that CR 
through should probably care. And whoever who is responsible for a codebase 
that evaluates multiple records as anything other than no record should also 
probably care. But the RFC clearly states that multiple records are not to be 
evaluated so this shouldn’t cause much drama, but who really knows…

 

Ken.

 

From: Bressier Simon  
Sent: Thursday 20 August 2020 14:18
To: Ken O'Driscoll 
Cc: Mailop 
Subject: Re: [mailop] Hotmail.tld DMARC record issue

 

so, you mean nothing wrong and nobody should care ?

 

Le jeu. 20 août 2020 à 15:12, Ken O'Driscoll via mailop mailto:mailop@mailop.org> > a écrit :

More than one DMARC record is functionally equivalent to having no DMARC record 
so this isn’t going to cause problems outside of incompetently written code.

 

Ken.

 

From: mailop mailto:mailop-boun...@mailop.org> > On 
Behalf Of Bressier Simon via mailop
Sent: Thursday 20 August 2020 13:24
To: mailop mailto:mailop@mailop.org> >
Subject: [mailop] Hotmail.tld DMARC record issue

 

Hi folks, just forwarding an email received on DMARC ML here, to see if someone 
from Microsoft could fix quickly:

 

Anyone from Microsoft in the list?

 

Our monitoring system reported last night that Hotmail changed its DMARC record 
and in the process a duplicate entry was created which might cause 
unpredictable behaviour.

 

; <<>> DiG 9.10.6 <<>> txt _dmarc.hotmail.com <http://dmarc.hotmail.com/> 

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23075

;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

 

;; QUESTION SECTION:

;_dmarc.hotmail.com <http://dmarc.hotmail.com/> . IN TXT

 

;; ANSWER SECTION:

_dmarc.hotmail.com <http://dmarc.hotmail.com/> . 300 IN TXT "v=DMARC1; p=none; 
rua=mailto:d...@rua.agari.com <mailto:d...@rua.agari.com> 
;ruf=mailto:d...@ruf.agari.com <mailto:d...@ruf.agari.com> ;fo=1:s:d"

_dmarc.hotmail.com <http://dmarc.hotmail.com/> . 300 IN TXT "v=DMARC1; 
p=reject; pct=100; rua=mailto:d...@rua.agari.com <mailto:d...@rua.agari.com> ; 
ruf=mailto:d...@ruf.agari.com <mailto:d...@ruf.agari.com> ; fo=1"

 

This is the case for .com and all other TLDs.

 

As I still have my 20-year-old Hotmail account I am an interested party :) 

 

Best,

Randal

 

--

Randal Pinto

Founder & COO

+447703108205  

@randalpinto <https://twitter.com/randalpinto> 

 

Red Sift is the power behind OnDMARC and OnINBOX.

You can find us at 21A Noel Street, 4th Floor, London, W1F 8GR.

 

Red Sift is a limited company registered in England and Wales. Registered 
number: 09240956. Registered office: Kemp House, 152 City Road, London, EC1V 
2NX.

___
mailop mailing list
mailop@mailop.org <mailto:mailop@mailop.org> 
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Hotmail.tld DMARC record issue

[Ken O'Driscoll via mailop]

More than one DMARC record is functionally equivalent to having no DMARC record 
so this isn’t going to cause problems outside of incompetently written code.

 

Ken.

 

From: mailop  On Behalf Of Bressier Simon via mailop
Sent: Thursday 20 August 2020 13:24
To: mailop 
Subject: [mailop] Hotmail.tld DMARC record issue

 

Hi folks, just forwarding an email received on DMARC ML here, to see if someone 
from Microsoft could fix quickly:

 

Anyone from Microsoft in the list?

 

Our monitoring system reported last night that Hotmail changed its DMARC record 
and in the process a duplicate entry was created which might cause 
unpredictable behaviour.

 

; <<>> DiG 9.10.6 <<>> txt _dmarc.hotmail.com  

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23075

;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

 

;; QUESTION SECTION:

;_dmarc.hotmail.com  . IN TXT

 

;; ANSWER SECTION:

_dmarc.hotmail.com  . 300 IN TXT "v=DMARC1; p=none; 
rua=mailto:d...@rua.agari.com  
;ruf=mailto:d...@ruf.agari.com  ;fo=1:s:d"

_dmarc.hotmail.com  . 300 IN TXT "v=DMARC1; 
p=reject; pct=100; rua=mailto:d...@rua.agari.com  ; 
ruf=mailto:d...@ruf.agari.com  ; fo=1"

 

This is the case for .com and all other TLDs.

 

As I still have my 20-year-old Hotmail account I am an interested party :) 

 

Best,

Randal

 

--

Randal Pinto

Founder & COO

+447703108205  

@randalpinto  

 

Red Sift is the power behind OnDMARC and OnINBOX.

You can find us at 21A Noel Street, 4th Floor, London, W1F 8GR.

 

Red Sift is a limited company registered in England and Wales. Registered 
number: 09240956. Registered office: Kemp House, 152 City Road, London, EC1V 
2NX.

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] From/Header information for Bounce processing emails

[Ken O'Driscoll via mailop]

> I want to gather as much information regarding this as possible - Focusing
> mainly on the most used ones like GoDaddy, etc.
> 
> Have you done a similar task/project like this?

Take a look at The SMTP Field Manual (https://smtpfieldmanual.com/) and  
Sisimai (https://libsisimai.org/en/). The Field Manual is mainly the different 
SMTP error codes while Sisimai (formerly BounceHammer) is a library for parsing 
bounce messages from a variety of providers.

Ken.


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Google G.Suite Mail admin

[Ken O'Driscoll via mailop]

On 24/07/2020 20:50, Curtis Maurand via mailop wrote:
Would you please contact me off list.  I'm having a strange 
deliverability problem to a specific user from a specific host and 
having a weird problem. I have admin access to both ends of the 
conversation.  Something is wrong in the middle and I think it's on 
your side of the middle.  It's very odd.


If you have access to both sides then open a support request with Google 
at the G-Suite end - the quality of paid support is really pretty good. 
Alternatively, you can post more details here and somebody might be able 
to provide assistance.


Ken.


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] G Suite Support - Deliverability Issues

[Ken O'Driscoll via mailop]

On Mon, 2020-06-08 at 19:12 +, Kotlikov, Anna via mailop wrote:
> Hello, 
> 
> Is there anyone here I can speak to from G Suite support?  
If you are a paying G-Suite customer then you are entitled to
comprehensive support from Google, which you can access via your
dashboard or via the details on their website.
This mailing list is not a support channel for any vendor.

Ken.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] How to allow different domain in envelope and header from? (Is Gmails DMARC check broken?)

[Ken O'Driscoll via mailop]

On Thu, 2020-06-04 at 12:06 +0200, Benoît Panizzon via mailop wrote:
> Our Support Case System (RT/3) uses a global configured envelope
> sender: but depending on the Queue, a different
> Header From:supp...@breitband.ch

We use RT too and same problem if a queue is whitelabeled to use a
client domain for outsourced support. One kludge is to get the MTA to
re-write the 5321.From (side-wide return-path) based on the 5322.From
(queue From) for outbound and, to keep the bounce processor happy,
reverse it back to the site-wide one for inbound emails. There is
obviously a DNS component too which I'm not getting into.
Ken.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Is Gmails DMARC check broken?

[Ken O'Driscoll via mailop]

On Wed, 2020-06-03 at 14:15 +0200, Benoit Panizzon via mailop wrote:
> > and I guess the domain in the HELO too?
> 
> the HELO contains the FQDN of the sending machine which is
> not the same as the domain of the envelope sender or From: Header.
> 
> The HELO needing to match anything for DMARC or SPF would be quite new
> to me.

The FQDN used in the HELO being part of SPF tests is nothing new at
all.

If you are using sub-domains of the 5322.From domain in the 5321.From
or SMTP HELO then those sub-domains need to have their own individual
SPF records too. For example, if they are single servers then "v=spf1
+a -all" is a simple option.

So in the absence of DKIM, even when using an enforcing DMARC policy
with relaxed SPF alignment ("aspf=r"), a message will fail the DMARC
test if sub-domains of the 5322.From are used in the 5321.From and/or
SMTP HELO and they do not have any (compliant) SPF records.

If you could share the specific FQDN values you are using it would
greatly help in helping you.

Ken. 
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Abuse contact for emailsrvr.com?

[Ken O'Driscoll via mailop]

On Wed, 2020-06-03 at 10:52 +, Olaf Petry via mailop wrote:
> Or would be ab...@rackspace.com the correct abuse address?

The emailsrvr.com domain is part of Rackspace's email service, so their
anti-abuse desk would definitely be the correct contact point.

Ken.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Is Gmails DMARC check broken?

[Ken O'Driscoll via mailop]

On Tue, 2020-06-02 at 17:04 +0200, Benoit Panizzon via mailop wrote:
> _DMARC.imp.ch descriptive text "v=DMARC1; p=none; rua=mailto: 
> dmarc-rep...@imp.ch; ruf=mailto: dmarc-rep...@imp.ch ;
> aspf=s"(reverted to p=none)
> That email was sent from: 2001:4060:1:1002::139:139 which passes SPF.
> Any idea what is going wrong? Is Gmail's DMARC implementation broken
> and REQUIRES DKIM violating RFC?

Without seeing the actual message my guess is that the aspf=s is the
problem. This is telling receivers that you want to enforce strict SPF
alignment, which means the FQDNs used the SPF tests must match. So, if
your 5321.From is using a sub-domain then this will fail a DMARC test
in the absence of DKIM.

Ken.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Google: 'Low reputation of the sending domain'

[Ken O'Driscoll via mailop]

On Tue, 2020-06-02 at 10:37 +0200, Benoit Panizzon via mailop wrote:
> DKIM is not a solution. I faced too many problems with mailinglists
> and similar which did alter the header and broke DKIM signatures.
> 
> Has anyone a hint what could be the cause for this problem?
> 
> And yes, disabling IPv6 seems to solve the issue, but that is the wrong
> way dealing with it :-)

This may be part of the issue. If you are using IPv6 then you really
need to be signing with DKIM. Mailing lists etc. breaking your DKIM
signature is pretty much expected behaviour and not a reason to disavow
it entirely.

Ken.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Microsoft Outlook "Modern Authentication"?

[Ken O'Driscoll via mailop]

On Thu, 2020-05-28 at 13:35 -0600, Daniele Nicolodi via mailop wrote:
> Does anyone know if there is any alternative to Outlook to access
> 
> Exchange Online mailboxes that require modern authentication?

Take a look at Davmail, it's basically a proxy that sits in-between
your existing "legacy" MUA and O365. It handles all of the MFA and
talks EWA then presents standards based IMAP, SMTP, CalDAV and CardDAV
protocol interfaces for your MTA to use.

I don't know if it will work for your specific environment but it works
for most people that what to continue to use Thunderbird etc. with
Exchange.

Ken.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Unable to receive email from WeTransfer and Facebook (only for a specific domain)

[Ken O'Driscoll via mailop]

On Sun, 2020-05-17 at 12:09 +0200, Alessio Cecchi via mailop wrote:
> I think that during the transfer of the domain some happened with 
> name server but I can't understand what.

There are many things that can go wrong with NS servers and the
networks they live on that can interfere with answering queries
correctly and/or consistently. However, you can only diagnose these
issues if you are the DNS provider.

So, In the case that

a) none of your other MX hosting domains are experiencing this problem,
b) the only thing that changed with stefanoboschi.it was the DNS zone
hosting, and
c) you are certain that you are not rejecting the emails or packets at
your end,
then I think a reasonable course of action would be talk to the DNS
provider to see what's happening at the query end. If the new DNS
provider is not cooperative then you could think about temporarily
moving the DNS to another provider (e.g. Amazon) to see if the problem
disappears.

It could of course be something else, but it would be good to at least
rule out DNS.

Ken.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Google Postmaster Tools Volume Requirements

[Ken O'Driscoll via mailop]

On Wed, 2020-05-13 at 11:18 -0700, Brian Toresdahl via mailop wrote:
> Any experience within this group with what Google means when they
> say:"If you send a large volume of emails to Gmail users, you can use
> Postmaster Tools to see: ..." (
> https://support.google.com/mail/answer/6227174?hl=en)
> What order of magnitude are they in practice requiring to qualify for
> "large volume"? 100 / day? 1000, 1?

You need to send at least 100/day.

Ken.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

[mailop] Google DMARC reports

[Ken O'Driscoll via mailop]

We haven't received a Google DMARC report for any domain since Tuesday
(21 Apr.), is anyone one else seeing this?

Ken.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Fwd: Invitation: INFO MAIL @ Sun Apr 19, 2020 11am - 12pm (MDT) (ge...@mulligan.com)

[Ken O'Driscoll via mailop]

On Sun, 2020-04-19 at 11:08 -0600, Geoff Mulligan via mailop wrote:
> I know that this is a scam, but what are they attempting to do? 
> Gain access to google through calendars?
> 
> 
> 
> Geoff

Calendar spam is nothing new. It's just an attempt to get around
filters by being visible outside of the inbox etc.

This is not the appropriate list for posting spam samples. Try the SDLU
(http://www.new-spam-l.com/admin/faq.html) list for that.

Ken.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] scaleway.com / online.net: Scammers, or just scammer friendly?

[Ken O'Driscoll via mailop]

On Thu, 2020-04-02 at 12:34 +0200, Tom Ivar Helbekkmo via mailop wrote:
> Anyone know something about these scaleway.com morons?  Should
> onefirewall their entire network ranges out completely, or just make
> sureone doesn't accept any SMTP connections from those ranges?

This is probably a discussion better suited for the SDLU list (
http://www.new-spam-l.com/admin/faq.html), it's the kind of stuff they
like to discuss.

Ken.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Spectrum webmail folks around?

[Ken O'Driscoll via mailop]

On Wed, 2020-02-26 at 17:07 +, Jay R. Ashworth via mailop wrote:
> My sister's inherited tampabay.rr.com account -- the only one we have to
> look at your webmail client with -- is unreasonably slow in retrieving mail
> from folders.  On my 16GB i7 with Win 10, it can take on the order of a minute
> to open a folder with 3 messages in it; much longer for things like the Inbox.
> 
> Ridiculously longer on less powerful devices, like her Android tablet.
> 
> I'm told this is a pervasive problem with the webmail service.  Is it, 
> perhaps,
> trying to implement an entire IMAP client in Javascript?
> 
> If there's anyone in that department at that carrier who can comment on this,
> that'd be great.

This list is not intended for provisioning end user support on provider
email services.

If you have problem with the webmail service provided by
Charter/Spectrum then you should open a support request with them. 

Ken.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Opinions? Email Abuse over TOR Network?

[Ken O'Driscoll via mailop]

On Sun, 2020-02-23 at 07:40 -0800, Roger Marquis via mailop wrote:
> Perhaps more interesting is the fact that the vast majority of ESPs don't
> even think about obfuscating _usernames_.  Are there good reasons to use a
> well known string like the email address for half of a credential?  While not
> the default it doesn't take much additional configuration to allow users to
> define their own MUA username which doesn't (and IMO shouldn't) have anything
> in common with their email address/es.

Technical support is the primary reason why ISPs don't obfuscate the
username into something difficult and hard to remember - like a
password. SSO using the email address as the username is the only
practical way to scale an email service where the end-users are assumed
to be non-technical. At the most basic level, forgetting their username
means they can't open a support request which means a telephone call to
support desk.

Implementing measures like 2FA along with policy based authentication
is the way to prevent this type abuse is a scalable manner.

Ken.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] ADMIN: Mailop in 2020

[Ken O'Driscoll via mailop]

On Sat, 2020-02-15 at 19:15 +1300, Simon Lyall via mailop wrote:
> The "new" website is up. It is fairly empty so far but we'd like to get it 
> expanded a bit.
> 
> There is a FAQ page with a few possible entries. We'd like to get these 
> filled out. The first entry is "Best Practices for running a mail server" 
> which could probably be a whole page by itself.
> 
> Suggestions as to content/questions/answers/links to put in would be 
> welcome.

Are you looking for volunteers to supply content for this? Because I'm
a good few of us have stuff already written that we could share.

Ken.


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] AT Block - abuse_...@abuse-att.net still valid?

[Ken O'Driscoll via mailop]

On Tue, 2020-02-11 at 10:50 -0500, Scott Mutter via mailop wrote:
> I suppose it's possible that AT is just inundated with abuse
> requests - but maybe there is a better way to weed out the valid
> requests from the invalid requests.
> 
> If abuse_...@abuse-att.net is no longer valid, then perhaps the
> rejection notice needs to be updated.

It's still valid and they do respond. But as you correctly surmise,
they are very busy answering tickets from non-customers so patience is
required. I'd typically give a request at least a week before poking
them again.

Ken.


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Messages from small personal SMTP server being marked as junk by Google

[Ken O'Driscoll via mailop]

On Fri, 2020-01-24 at 09:47 +, Gregory Heytings via mailop wrote:
> This is not optimal, your SPF record should be "v=spf1 mx ?all".

This is incorrect advice. The original poster's existing SPF is fine.


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Messages from small personal SMTP server being marked as junk by Google

[Ken O'Driscoll via mailop]

On Thu, 2020-01-23 at 21:24 -0600, John Gateley via mailop wrote:
> There were 19 recipients on the To: line.
> 15 of the recipients were gmail addresses.
> 
> Any ideas why? Or how I fix it?
> The mail server is too small (much much less than 100 messages per day) 
> so I cannot check Gmail's tools for this.

Once the recipients remove the message from their spam folder, the problem
will likely start to disappear as the mailbox provider will realise that
email from this address is wanted.

I'd strongly advise setting up a distribution list for each class on
Postfix so that she avoids cramming lots of (presumably freemail) addresses
into the To field - it's not a great signal for a micro sender.

Another thing she can do is encourage the class to add her email address to
their address books when she gives it out first - this will strongly reduce
the likelihood of the first email going to spam. Or, get them to email her
their addresses, them emailing the address will also have a positive
effect.

Good luck.

Ken.


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] mx abuse listed in spamhaus?

[Ken O'Driscoll via mailop]

On Tue, 2020-01-14 at 10:44 +, J Orlando Letra via mailop wrote:
> does any one have this problem?
> 

As per https://www.abuseat.org/lookup.cgi?ip=64.57.183.53 the IP was
detected sending or relaying IP traffic which matches a known virus botnet
signature. In this case the "ranbyus" virus.

Something is infected.

Once you have cleaned up your server / site you can request removal from
the list at the end of that page. Be aware, that if you do not clean your
site before requesting de-listing, your IP may be permanently re-added to
the list with no option to remove it.

Ken.


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Rackspace/SenderScore personnel here can comment on this?

[Ken O'Driscoll via mailop]

On Fri, 2020-01-03 at 12:05 +, Ken O'Driscoll via mailop wrote:
> $ dig fbl.senderscore.net mx
> 10 ss-mx00.senderscore.net.

(hit send on the wrong email - to continue...)

fbl.senderscore.net is what they've used in the past so perhaps it's a user
on-boarding issue.

However, I wouldn't have any expectation that emails sent to RFC2142 type
addresses would pass spam filter tests. Was it a valid RBL report?

Ken.


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Rackspace/SenderScore personnel here can comment on this?

[Ken O'Driscoll via mailop]

On Thu, 2020-01-02 at 16:54 -0800, Michael Peddemors via mailop wrote:
> The header from is :feedbackl...@rackspacefbl.senderscore.net", however 
> there is no A or MX record for that domain..

$ dig fbl.senderscore.net mx
10 ss-mx00.senderscore.net.

Ken.


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Telus Contact

[Ken O'Driscoll via mailop]

On Thu, 2019-12-19 at 17:18 -0500, Oreva Akpolo via mailop wrote:
> Hey there,
> 
> Does anyone know the point of contact or who from telus.net I can reach
> out to? I've had no luck finding a postmaster address.

ab...@telus.com gets to the postmaster as far as I recall. 

Ken.


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] G-Suite removing LSA functionality

[Ken O'Driscoll via mailop]

On Mon, 2019-12-16 at 17:45 -0800, Brandon Long via mailop wrote:
> If you wanted something, you'd probably want a proxy, something that
> speaks enough IMAP to do LOGIN/AUTHENTICATE, then re-login to
> Gmail with OAUTHBEARER, and then just be a pass through.  We do something
> similar for the reverse proxy for IMAP at Gmail, though again,
> not really code that can be shared... though maybe someday someone will
> write an Envoy module for that.  You could probably write
> something like that in a couple hundred lines of code.

For people looking for a proxy to sit in front of G Suite's OAuth, I'd
recommend taking a look at Davmail[1].

Davmail has been letting "traditional" clients talk to Exchange for ages,
providing them with good ol' IMAP, SMTP, CardDAV and CalDAV interfaces. It
already supports OAuth for O365. Since the dev team have already done a lot
of the heavy lifting, contributing to that project and extending it might
not be the worst idea for people looking for a proxy.

Ken.

[1] http://davmail.sourceforge.net/index.html



___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] G-Suite removing LSA functionality

[Ken O'Driscoll via mailop]

On Mon, 2019-12-16 at 22:30 +0100, Jaroslaw Rafa via mailop wrote:
> Do any Windows/Linux/MacOS email clients currently support OAuth "out of
> the box"?
> If not, that's basically cutting nearly everybody using regular IMAP
> email clients off of G Suite...

For Linux, the Gnome Online Accounts supports OAuth for Google, and has
done for quite a while. Which means that any client that can talk to that
framework, gets email, contacts and calendar/tasks. It also provides access
to Google Drive.

I've used Evolution (which talks GOA) for years with multiple G Suite
accounts and it works like a treat. And that's in a work capacity, not as a
home user/hobbyist so I'm unforgiving of problems.

KDE have their own authentication framework which Kontact (KMail etc.)
talks to but I have no idea of how stable the Oauth stuff is.

Ken.


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Comcast.net contact ? Unusually high amount of email being deferred.

[Ken O'Driscoll via mailop]

On Mon, 2019-12-02 at 17:08 +, Ryan Prihoda via mailop wrote:
> defer (-53): retry time not reached for any host for 'comcast.net'

That looks like an MTA (Exim?) error, and not a SMTP 4xx type message.

You need to work out if the messages are backing up because a) Comcast are
throttling you or b) you have a local configuration issue.

If you are being throttled then you'll see an SMTP 4xx type message in your
logs generated by the Comcast MX servers in response to your attempt to
deliver to them. The messages will stay in the queue and delivery re-
attempted as per the local MTA setting.

If the error messages is being generated by the MTA software itself, then
that could be a local server misconfiguration, network or resource issue.

My advice would be to look at all of your logs, not just the maillog.

Ken.


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Comcast.net contact ? Unusually high amount of email being deferred.

[Ken O'Driscoll via mailop]

On Mon, 2019-12-02 at 16:01 +, Ryan Prihoda via mailop wrote:
> I do not know what else I could do so hopefully someone on the list can
> help me out.

Without knowing exactly what the SMTP message is, I just guessing that
you're being throttled because you are sending too much too quickly.

Take a look at the Comcast Postmaster guidelines:
https://postmaster.comcast.net/avoidblocks.html

Follow everything on that page especially the sending limits outlined.

Ken.


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] MegaRbl ?

[Ken O'Driscoll via mailop]

On Mon, 2019-11-25 at 16:25 +0300, Emre Üst via mailop wrote:
> Hello everyone , 
> 
> Is anybody know this French blacklist firm megarbl.net ?  I think
> something is wrong in their systems . 

According to Slack this morning, it's been dead for years but the (new)
domain owner seems to have changed the query response recently.

Rip it out from any filtering or monitoring configs.

Ken.


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] reputation with DKIM when d= differs from sender domain?

[Ken O'Driscoll via mailop]

On Thu, 2019-11-14 at 16:38 +, Stefan Bauer via mailop wrote:
> 
> Is it bad - in terms of reputation - when domain in dkim-header (d=...)
> differs from senders address?
> signing is done correctly and pub-key is present at domain of corse -
> specified with d=...
> 
> like d=mydomain.com
> Sender is Stefan 

By itself there's no adverse impact on reputation. Same goes for sub-
domains.

Reputation is something which is built up over time. So keeping the same
DKIM signing configuration is often preferable to changing it purely for
aesthetic reasons, and this is especially true for already established
large volume senders.

Also, it matters a lot if you are planning to implement DMARC[1], but for
very different reasons.

Ken.

[1] https://dmarc.org/


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Zohomail & Carrierzone

[Ken O'Driscoll via mailop]

On Thu, 2019-10-31 at 11:05 -0700, Autumn Tyr-Salvia via mailop wrote:
> I don't have a lot of familiarity with either provider. Does Zohomail do
> no domain validation before relaying messages, or does this indicate a
> broader compromise? 

On any Zoho service I'm familiar with, they do implement sending domain and
address (LHS) validation.

Their DKIM signing domain is usually customised to indicate what service
was used to send the email.

If you think it's an exploit of a Zoho service, reach out to them.

However, it may also be:

1. incorrectly forwarded email from their hosted email offering, or
2. indication of a rogue marketing effort within the organisation.  

> Does Carrierzone ignore DMARC and SPF? I'm interested to hear other
> people's experiences with these providers.

I have no idea, but remember they're not obliged to do so and, judging what
they do (outsourced abuse desk), might not run filters in an expected way.

Ken.


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Low-Volume Domains\Servers

[Ken O'Driscoll via mailop]

On Fri, 2019-10-25 at 11:34 -0500, Mike Hammett via mailop wrote:
> One time one of them told me that because my normal volume was so low,
> they didn't have much to go on for validating the problem had been
> corrected.

Exactly how low is low?

I work with some smallish ISPs and they don't have this issue so hence why
I ask.

Ken.


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Autofiling spam mail in Junk folder

[Ken O'Driscoll via mailop]

On Wed, 2019-10-23 at 13:21 +0200, Daniele Duca via mailop wrote:
> On 23/10/19 13:09, Ken O'Driscoll via mailop wrote:
> 
> >
> > You can set up local mail filtering rules in Outlook to place certain
> > emails in a folder. Is that what you mean?
> 
> The problem is that explaining end users to create a filter is much more 
> time consuming that just say "Go to Account Settings -> Junk settings 
> and enable Trust junk mail headers set by SpamAssassin" if they use 
> Thunderbird. I'm trying to cut down time spent on end-user support :)
> 

If you're delivering to a local Exchange server with a message store then
you can configure the filter on the server and it will move emails to the
spam folder for each user. The level of knowledge to achieve that is within
the realms of whoever set up the server in the first place. Similar can be
achieved with other on-site solutions.

If you're the one providing mailbox hosting then just do it yourself or
make it an option for the end users to opt-in to.

This is all pretty basic functionality which have been around for years so
perhaps I'm missing something?

Ken.


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Autofiling spam mail in Junk folder

[Ken O'Driscoll via mailop]

On Wed, 2019-10-23 at 12:08 +0200, Daniele Duca via mailop wrote:
> Does anybody knows a way 
> to tell Outlook to do what Thunderbird does?

You can set up local mail filtering rules in Outlook to place certain
emails in a folder. Is that what you mean?

Ken.


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] seeking Samsung contact

[Ken O'Driscoll via mailop]

Hi Ricardo, 




If it's the native email client that they bake into the handsets, I think that 
gets its provider data from a DB maintained by Mozilla. If that is the case, 
the good news is that it's updateable.




The other thing to check is if someone at your org previously created SVR 
records for locating email servers (as per RFC 6186 or 6168?) and forgot about 
them. On mobile so can't check if those records exist or make sure I ref'ed the 
right RFC.




Ken.







On Tue, Sep 3, 2019 at 12:28 PM +0100, "Ricardo Signes via mailop" 
 wrote:










Samsung is doing auto-configuration of mail clients based on dated, wrong data. 
 I'm looking for a contact who can help get this sorted out.
--
Ricardo Signes (rjbs)
CTO, Fastmail








___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Amazon AWS SES (Simple Email Services) what could cause a domain to be blocked?

[Ken O'Driscoll via mailop]

On Tue, 2019-08-13 at 09:44 +0200, Benoit Panizzon via mailop wrote:
> My attempt to open a 'user' account on Amazon (the one you can order
> stuff) also didn't help much further as this account also has no way to
> open an AWS case or access the existing case the Amazon SES customer
> opened.

Sign in with your regular account at the AWS console here:
https://aws.amazon.com

This will prompt you to sign up to becoming an AWS user.

Support is tiered. The included support is basically sales support so pay
to upgrade to (at least) the next tier.

You will need to actually set up your own SES instance properly and then
attempt delivery to your site as support won't respond to tickets created
under other accounts. When I say properly I mean white labeling with a test
domain etc.

Ken.


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Paging Proofpoint - possible issue with SSL cert for SORBS website

[Ken O'Driscoll via mailop]

On Fri, 2019-08-09 at 09:43 +1000, Michelle Sullivan via mailop wrote:
> They are there and apache configured to know about them... (and I'm not 
> getting any warning on Safari or Seamonkey.)

The reason I though the server wasn't serving intermediate certs was
because:

$ openssl s_client -showcerts -connect www.secure.sorbs.net:443
depth=0 businessCategory = Private Organization, jurisdictionC = US, 
jurisdictionST = Delaware, serialNumber = 3540718, C = US, ST = California, L = 
Sunnyvale, O = "Proofpoint, Inc.", CN = www.secure.sorbs.net
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 businessCategory = Private Organization, jurisdictionC = US, 
jurisdictionST = Delaware, serialNumber = 3540718, C = US, ST = California, L = 
Sunnyvale, O = "Proofpoint, Inc.", CN = www.secure.sorbs.net
verify error:num=21:unable to verify the first certificate
verify return:1
[...]

And, in case those redirects might somehow interfere with the test:

$ curl https://www.secure.sorbs.net/scgi-bin/login
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html
[...]

There does appear to be some problem with Firefox accessing that URL[1].

Another thing that came to mind is that both Firefox and my workstation are
using the Mozilla CA store while Chrome uses the Google one. As noted by
Andrew, Qualys also reports an issue and I believe based on KB articles
they too use the Mozilla CA store. So it may possibly be the case that the
server isn't serving sufficient/correct intermediate certs to create a
chain of trust for all CA stores.

Ken.

[1] https://pasteboard.co/IrSMRsC.png



___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

[mailop] Paging Proofpoint - possible issue with SSL cert for SORBS website

[Ken O'Driscoll via mailop]

As per a discussion on a emailgeeks today, it seems that Firefox is
throwing up a CA not trusted security alert for visitors to https://
www.secure.sorbs.net

I can reproduce on Firefox but not Chrome.

A cursory glance shows the server doesn't appear to offer intermediary
cert(s) which may be connected to the issue.

Ken.


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Lost GPT Ownership

[Ken O'Driscoll via mailop]

On Wed, 2019-07-17 at 09:02 -0400, Tracey Crawford via mailop wrote:
> One of our clients lost owner privileges to one of their domains in
> Google Postmaster Tools.  Does anyone know how we can recover ownership
> to the domain?  They have read access, but that does not allow them to
> manage the domain.  We've tried deleting the domain and re-adding, but
> that does not give us a new verification record and therefore, We still
> only have read access.
> 

Hi Tracey,

they should be able to reset ownership via the Search Console (previously
Webmaster Tools). GPT domain ownership is subservient to that as far as I
understand.

Ken.


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Moving to a new outbound IP range

[Ken O'Driscoll via mailop]

On Mon, 2019-07-01 at 12:55 +0100, Simplelists - Andrew Beverley via mailop
wrote:
> Would it be better to go for the brand new block? Obviously any
> existing block could be checked in DNSBLs etc, but are there any
> advantages of using an existing block?

The lack of historical RBL listings is nowhere close a definitive
indication that the IP space wasn't used for abusive purposes at some
point. BGP hijacking, malicious site hosting, hijacked POS endpoints etc.
all get clocked in databases, some of which have long memories and are not 
publicly available. It's often not immediately obvious that such a range
has a poor reputation somewhere so you end up wasting time etc.

A new direct allocation has zero reputation, good or bad.

If you are lucky enough to have the option, my preference would be to go
for a new allocation since it removes some variables.

Ken.


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Invalument SIP/24

[Ken O'Driscoll via mailop]

On Thu, 2019-06-27 at 10:50 -0500, Al Iverson via mailop wrote:
> Rob, you're treating it as an attack when I don't really think it is.
> Why not just say sure, I can help you with this, sorry we didn't
> connect before, let's do that now.
> 
> Your rep will survive the occasionally misplaced complaint -- every
> blacklist maintainer, especially good ones, know that people freak out
> sometimes.

Since this is a publicly available list[1] with posts appearing in search
engine results, I think we should be sympathetic to any vendor who wished
to deliver a verbose response to those who mistake here for a support
forum.

Ken.

[1] https://www.mail-archive.com/mailop@mailop.org/index.html



___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] G postmaster issue since 13th ?

[Ken O'Driscoll via mailop]

Can see the same issue across multiple client domains. Most stop on June
13th but some appear to have stopped reporting earlier, in May or April.

Ken.


On Wed, 2019-06-19 at 10:13 +0200, Bressier Simon via mailop wrote:
> Hey guys !
> 
> We have no datas from Google Postmaster tools since 13th June, Brandon,
> do you know if someone already aware/working on that ?



___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Google response

[Ken O'Driscoll via mailop]

On Fri, 2019-06-07 at 08:43 -0400, MikeO via mailop wrote:
> Quick question, Ive not seen this before.  Have a customer that is
> sending into  Google, its being accepted but then bounced back out with
> The response was:
> The account l...@xx.com is disabled.
>  
> But that address is the From  not the google mailbox it was sent to

Without knowing the actual domain names in questions all I can do is guess
that the problem may be a) the sending domain was (recently) formerly a G
Suite account before leaving in some unplanned manner or b) an incorrect
variable referenced by Google.

Ken.


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Howto be a good mailop (best practice / insights wanted)

[Ken O'Driscoll via mailop]

On Fri, 2019-05-31 at 11:03 +, Stefan Bauer via mailop wrote:
> Hi Ken,
> 
> thanks again for your input. Regarding
> Add a custom header (X-abuse)
> 
> is this really a thing? Could not find many mails in my inbox with that
> header present at all nor any official recommendations about that.
> Stefan

Hi Stefan,

Yes, it is fairly popular with ESPs (X-Report-Abuse, X-Complaints-To are
fairly common sights). Also web hosting providers and commercial SMTP
services (like you) tend to add a few custom headers to identify specific
subscribers. It's not universal by any means but I'd recommend it for the
service you're offering.

And, to to be fair, RFC 6648 (which is a best practice not a standard)
depreciates the use of the "X-" prefix in favour of general meaningful
custom headers (e.g. Complaints-To) so doing that is probably better.

Does that answer your question?

Ken.


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Any contact to Google to debug 'aspmx' troubles?

[Ken O'Driscoll via mailop]

Hi Benoît,




There's no blanket issue with RT and Google, we use it and so does one of our 
clients without issue.




Does it work when you reply from the web interface?




Ken.







From: Benoit Panizzon via mailop


Sent: Monday 27 May, 11:10


Subject: [mailop] Any contact to Google to debug 'aspmx' troubles?


To: mailop@mailop.org






Hi all I'm looking for a contact to Google (or anyone with insight on what 
could cause the problem) to solve a specific issue we have with a company using 
their ASP services. Observed Problem: I send them an email from the email 
client 'claws-mail'. This is received perfectly. But we use RT/4 as issue 
tracking system. If I reply to a case we have open with them. They do not get 
my reply, despite our logs showing a successful delivery to aspmx.l.google.com 
and no late bounces being received. We did try different recipients in their 
domain, it's the same for all of them. It looks a bit like as if google is 
silently dropping everything with: Precedence: bulk or X-Managed-BY: RT 4.2.12 
(http://www.bestpractical.com/rt/) Mit freundlichen Grüssen -Benoît Panizzon- 
-- I m p r o W a r e A G - Leiter Commerce Kunden 
__ Zurlindenstrasse 29 Tel 
+41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web 
http://www.imp.ch __ 
___ mailop mailing list 
mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop 





___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Howto be a good mailop (best practice / insights wanted)

[Ken O'Driscoll via mailop]

On Wed, 2019-05-08 at 16:45 +, Stefan Bauer via mailop wrote:
> we have in place:
> 
> only allow pre-defined sender-addresses after auth
> monitor mail-queues for high connection count
> monitor RBLs if we're listed
> only allow single mail / 5s to be sent outgoing
> anti-virus checking of attachments

Hi Stefan,

off the top of my head I would add:

 * Monitor abuse@ and make sure that this address a) exists for your client
   domains and b) you receive a copy of messages sent to them.
 * Restrict access to the submission port to either the client IP range.
 * Lock accounts after X failed logins and get an alert about that.
 * Have a third (failover/fallback) sending capability with a different
   data centre. Periodically route enough email though that to ensure that
   it will not be throttled in case you need it. But, don't use it as a
   primary.
 * Understand what your normal usage profile looks like - graph the mail
   queues. This will help you build policies / tech. around detecting
   unusual behaviour. E.g. tougher throttling outside of business hours
   etc.
 * Add a custom header (X-abuse) to make it clear where the email came from
   and how to report abuse of your service.
 * Make it clear on your website how a non-customer can contact you to
   report abuse.
 * Run a cut-down spam filter on the outbound mails (look for stuff like
   freemail reply to addresses, fuzzy checksum hits, spam URLs). Some of
   that will be false positives so just put it into a holding queue and
   create a service desk ticket for it to be reviewed.
 * Have a clear upgrade path if case they wish to send marketing emails. If
   you don't, they will just try to send them through your platform.
 * Publish an Acceptable Use Policy (AUP) and make them agree to it as a
   pre-condition to using your service. Spamhaus have a good template to
   start from on their website.
 * Monitor bounces and tie that it with your monitor solution.
 * Monitor the health of your clients connecting IPs (and possibly
   website). Any indication of a compromised site is grounds for locking
   the account until a human can review. 
There is likely more, above is, as I said, off the top of my head. Good
luck.

Ken.


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Outgoing messages currently blocked by hotmail, google, outlook etc (any way to unblock?)

[Ken O'Driscoll via mailop]

On Fri, 2019-04-26 at 15:01 +0100, Gary Hussey wrote:
> e was a victim of a spam session where approximately 200k spam emails was
> trying to leave our server over the bank holiday weekend. On tuesday this
> was discovered and around 50k had left our server. This was resolved but
> we are still experiencing some email bounce backs from outlook / google
> etc as suspicious activity, when in fact they are legitimate emails.
> 
> We use our own mail server and use MX records to send out (we are with
> BT)
> 
> What can we do, if anything to alleviate/speed up this (I assume
> temporary) ban?

Hi Garry,

in addition to ensuring that the source of the spam outbreak is fully
closed down and can not re-occur in the future, I'd suggest the following:

   1. publish an SPF policy for ddi-ltd.co.uk,
   2. sign outgoing messages with DKIM,
   3. implement Forward-confirmed Reverse DNS for your outbound SMTP server
  (mail2.ddi-ltd.co.uk) and
   4. apply to be de-listed from the SenderScore RBL.

If your mail stream has returned to normal then typically mailbox providers
will start to let your mail through again but, as you have seen, it is not
instantaneous. Complying with best current practices as per the above will
help.

Ken.


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Looking for GoDaddy email/DNS contact

[Ken O'Driscoll via mailop]

On Thu, 2019-04-25 at 22:49 -0500, frnk...@iname.com wrote:
> We had a customer not renew their domain name (IRONINGENUITY.COM), but
> upon expiration their MX records were left still pointing to us.  We're
> looking for a way for that to get cleaned up (ideally null MX record,
> second best is to reset to GoDaddy's default MX record for such domains),
> but since the customer doesn't want to renew the domain, don't know
> really where to turn.
> 

You can't stop a domain owner from pointing a resource record at you.

After the expiration grace period the domain will go into quarantine and it
will no longer resolve. By the time it becomes available for registration
again, all historical data (DNS, registration data etc.) will be gone.

All you can do is refuse services for the domain.

Ken.


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Zoho Feedback Loop

[Ken O'Driscoll via mailop]

On Tue, 2019-04-23 at 08:38 -0600, Josiah Ritchie wrote:
> I'm trying to sign up for the Zoho feedback loop and am finding that I
> never get a confirmation email so I can move forward. I know Yahoo is
> also having problems, checked again this morning and seems to be still be
> a thing, but I haven't heard that Zoho was. I tried contacting their
> support email a week ago, but haven't heard back. 
> 
> Anyone know if this is also systemic? 

I've set up a few for clients over the past 6 months and I don't recall
ever seeing a confirmation email other than to validate the address. Though
their FBL does work as expected.

What does the dashboard report the "status" of the application to be?

Ken.


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Sophos Time of Click protection

[Ken O'Driscoll via mailop]

On Thu, 2019-02-14 at 10:09 +0100, Stefano Bagnara wrote:
> So, before I propose to use local whitelisting I'd like to understand
> the global blacklisting causes :-)
> (If there is some malicious activity going on we better find it,
> instead of working around it)

I understand. The following, in case you don't already know about them, can
be useful sites for checking on URL/IP reputation outside of traditional
RBLs:

https://talosintelligence.com/ (Cisco)
https://reputationauthority.org/ (WatchGuard)
https://exchange.xforce.ibmcloud.com/ (IBM)

Ken.

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Strato Postmaster around? relay.rzone.de does not offer STARTTLS

[Ken O'Driscoll via mailop]

On Wed, 2019-02-13 at 07:31 +, Stefan Bauer wrote:
> As alot of sites nowadays enforce TLS, this is a showstopper, when the
> primary MX is rejecting connections by greylisting, sender tries
> second(backup) mx and fails due to missing STARTTLS. If the backup mx
> would also use greylisting, the client would come back later to primary
> MX and would be able to deliver.

Hi Stefan,

The vast majority of public MX servers do not enforce TLS, they offer 
opportunistic TLS whereby TLS is supported if asked for but a plaintext
SMTP conversation is still supported. 

From RFC 3207:

   A publicly-referenced SMTP server MUST NOT require use of the
   STARTTLS extension in order to deliver mail locally.  This rule
   prevents the STARTTLS extension from damaging the interoperability of
   the Internet's SMTP infrastructure.  A publicly-referenced SMTP
   server is an SMTP server which runs on port 25 of an Internet host
   listed in the MX record (or A record if an MX record is not present)
   for the domain name on the right hand side of an Internet mail
   address.

Likewise, if your public MX server required TLS when speaking with other
public MX servers, regardless of whether or not they offer it, that is your
"showstopper".

Ken.

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Sophos Time of Click protection

[Ken O'Driscoll via mailop]

On Tue, 2019-02-12 at 11:13 +0100, Stefano Bagnara wrote:
> I'm pretty sure it's a false positive as we have no other report about
> malicious contents on our site or the site of the sender, but I never
> seen this Sophos "Time of Click" protection before: do you know if
> there is a lookup website to see which URLs are listed? Do you have
> any experience with this "click-time" block service?

From recollection, Sophos used to use McAfee's engine in some of their
products so maybe try  https://trustedsource.org/ but my info might be out
of date.

Also, the recipient is empowered to whitelist you at any time, regardless
of what Sophos product they are using.

Ken.

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Sending e-mails to Yahoo! - What other tricks do you use?

[Ken O'Driscoll via mailop]

On Mon, 2019-01-14 at 18:55 +0300, Odhiambo Washington wrote:
> Heheee. I didn't know that Yahoo algorithms trust high volumes. Now I do,
> but this is not a solution.
> Going to search for an ISP (or a relay service) that is known to be
> "trusted" by Yahoo, because it sends enough volumes to Yahoo
> servers doesn't sound like something anyone would wish to go after when
> they have their own server.

You misunderstood me. It is not that Yahoo automatically trusts high volume
senders, it is that Yahoo need to see a reasonable sample of email from a
sender before making decisions regarding how to treat that email.

In your case, one possible reason for the delays could be that they do not
see enough volume from your IP address to make a determination that your
email does not need to be delayed.

Since individual emails are probably not experiencing delays, you could
just route the list traffic through Amazon SES (or similar) - thus keeping
your independence as a mail server operator.

Again, tiny volumes may not be the cause of the issue, I'm just speculating
based on your assertion that you are doing everything else correctly. 

Ken.

-- 
Ken O'Driscoll / We Monitor Email
t: +353 1 254 9400 | w: www.wemonitoremail.com

Need to understand deliverability? Now there's a book:
www.wemonitoremail.com/book


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Sending e-mails to Yahoo! - What other tricks do you use?

[Ken O'Driscoll via mailop]

On Mon, 2019-01-14 at 16:02 +0300, Odhiambo Washington wrote:
> I have a mailing list that has 1100 members. Out of those, 177 have Yahoo
> addresses.

Assuming you're compliant and doing everything right, that might be your
problem right there.

Unless you have a really really active list, it could be that you simply
send too small a volume of email and/or too infrequently from your server
for Yahoo! to notice you and make exceptions.

If that is the case, the solution would be to mix your list traffic with
other legitimate emails, such as through a shared SMTP service offered by
your ISP, through an ESP or Amazon SES etc. 

Yahoo! don't offer a whitelist facility. 

Ken. 

-- 
Ken O'Driscoll / We Monitor Email
t: +353 1 254 9400 | w: www.wemonitoremail.com

Need to understand deliverability? Now there's a book:
www.wemonitoremail.com/book


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

[mailop] Paging belgacom.be / proximus.com

[Ken O'Driscoll via mailop]

One of your DMARC aggregate report addresses (fdm...@proximus.com) is
invalid and generating bounces.

Happy Christmas.

Ken.

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Google and domain blacklisting

[Ken O'Driscoll via mailop]

On Mon, 2018-12-17 at 10:43 +0300, Odhiambo Washington wrote:
> Hi,
> 
> I hope there is someone from Google lurking around, or someone knows
> someone there.
> I have a domain that has been flagged (for phishing or identity theft, or
> maybe another thing) and I have submitted a request for clearance to
> Google
> via https://safebrowsing.google.com/safebrowsing/report_error/?hl=en, but
> it's a week now and nothing is happening.
<...snip...>

Pretty sure that form is for telling Google that they made a mistake in
classifying your site as malicious, not for requesting a rescan.

My advice would be to sign up to the Google Search Console (a.k.a.
Webmaster Tools) and request a rescan from there after you are sure that
you have addressed any issues displayed there.

Ken.

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Just Make It Stop

[Ken O'Driscoll via mailop]

On Thu, 2018-12-13 at 13:19 -0500, John Levine wrote:
> Anyone I can contact there to Just Make It Stop?

Does the mailbox provider/MTA support restricting senders to those already
in the address book? I've seen this work very well in a broadly similar
scenario.

Or, there's always CR... ;)

Ken.

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] MailChimp and TLS

[Ken O'Driscoll via mailop]

On Mon, 2018-12-10 at 11:21 -0500, Matthew Grove wrote:
> Hi Ken,
> 
> We have a mix of older and newer server configurations. The older ones
> can't handle TLS and maintain their current output, but we wanted to go
> ahead with TLS where possible. We will be working to update all servers
> and make TLS more consistent, but it'll take a little time.
> 

Thanks Matthew for clarifying that. I suspected similar but didn't have
sufficient visibility to be certain.

Ken.

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

[mailop] MailChimp and TLS

[Ken O'Driscoll via mailop]

Hi everyone,

I have a client who uses MailChimp. Now, I have noticed that for this
particular customer's campaigns, MailChimp does not always appear to
attempt to initiate (not a failed negotiation etc.) STARTTLS when talking
to our mail server. It does sometimes, but not always.

While I completely accept that our mail server could be at fault, the GPT
encryption graph also indicates their domain has a very poor inbound TLS
rate.

MailChimp is one suspect, there are others which are being investigated.

It would be super helpful if any mailbox provider here could tell me what
they see with MailChimp regarding TLS.

Thanks in advance,

Ken.

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Unsubscribe

[Ken O'Driscoll via mailop]

On Wed, 2018-10-31 at 15:37 +, Tracy Morgan wrote:
> Please unsubscribe me.

Hi Tracy,

you may unsubscribe by clicking the URL at the end of each email and
following the instructions for unsubscribing. Please note that the SSL
certificate has expired and your web browser will flash up a warning
requesting that you allow the connection. This is a know issue and, unlike
say, online banking, does not pose any security risks.

Alternatively you may email mailop-requ...@mailop.org with the subject
"unsubscribe".

Ken.


-- 
Ken O'Driscoll / We Monitor Email
t: +353 1 254 9400 | w: www.wemonitoremail.com

Need to understand deliverability? Now there's a book:
www.wemonitoremail.com/book


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop