Re: [mailop] Microsoft Consumer Email Deliverability Issue

2021-05-01 Thread Matt Corallo via mailop 
As far as I can tell, there's nothing you can do. You can try a non-Hetzner IP, sure, but plenty of people on here (like 
me!) have a dedicated IP in their own IP space for sending mail and still go straight to Hotmail-Junk.


Rate limiting might help, but if you send too *few* mails Microsoft's way 
you'll definitely go straight to Hotmail-Junk.

I think the only real option is to pay Validity money and get Return Path certification, but I haven't gotten far enough 
to actually pulling the trigger there to see if it solves the problem, and certainly for small senders it might entirely 
not.


Maybe you can pay someone large to relay your SMTP outbound when its headed to Microsoft (with associated configuration 
requirements).


Matt

On 5/1/21 16:44, Pierre Ozoux via mailop wrote:

Hi!

(I'm new here, so if I'm doing mistakes, do not hesitate to tell me with MP, or 
public, I'd like to respect the community)


We are a small provider based in France ( https://indiehosters.net ) and we have all in place (DMARC, DKIM, PTR, SNDS, 
JMRP, and a really strict SPF)


Since a year, we are marked as spam in Microsoft and it is painful.


We are offering a free software alternative as a service for people that don't know much about tech, and before we were 
offering a Nextcloud + email + domain to people, but since a year we stopped offering email. Just because of that, we 
don't feel comfortable.


(and yesterday a customer canceled because of that issue :/ )


I think we tried everything, maybe not yet the outbound rate limiting. It is my 
next step. Do you think it will help?


We also use hetzner, I guess their IP range doesn't have a good reputation, but we have this IP since more than a year 
now. Do you have a recommendation for a provider that would have a better reputation?



I'm also planning on asking all my friends with outlook account to mark my emails as non spam, maybe it will help the 
algorithm?



When I read the answer of microsoft support, I feel like in the process of Kafka, I'm being accused of wrong doing, and 
I don't know why..


If the big tech want to push AI, I think they have to polish the user experience right now, but currently, it is sending 
the really wrong signal I'd say..



Here is the snippet:


8<-

We have reviewed your IP(s) (195.201.199.169) and determined that messages are being filtered (i.e. sent to the Junk 
folder) based on the recommendations of the SmartScreen® Filter.


Email filtering is based on many factors, but primarily it's due to mail content and recipient interaction with that 
mail. Because of the proprietary nature of SmartScreen® and because SmartScreen® Filter technology is always adapting 
and learning more about what is and isn't unwanted mail, it is not possible for us to offer specific advice about 
improving your mail content. However, in general SmartScreen® Filter evaluates specific words or characteristics from 
each e-mail message and weights them, based on their likelihood to indicate that a message is unwanted or legitimate mail.


Unfortunately, after reviewing the information you provided and in compliance with our mail policies, we are unable to 
offer immediate mitigation for your deliverability issue. However, we have some specific recommendations for you to 
consider that can help you to improve deliverability over time.


-->8--



If it can help identify the issue here is one header of an email marked as spam:

8<-

Received: from SN1NAM01HT088.eop-nam01.prod.protection.outlook.com (2603:10d6:1:13::14) by 
SC1PR80MB5840.lamprd80.prod.outlook.com with HTTPS via SC1PR80CA0111.LAMPRD80.PROD.OUTLOOK.COM; Wed, 28 Apr 2021 
21:14:08 + Received: from SN1NAM01FT012.eop-nam01.prod.protection.outlook.com (10.152.64.54) by 
SN1NAM01HT088.eop-nam01.prod.protection.outlook.com (10.152.64.185) with Microsoft SMTP Server (version=TLS1_2, 
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.21; Wed, 28 Apr 2021 19:14:02 + Authentication-Results: 
spf=pass (sender IP is 195.201.199.169) smtp.mailfrom=indie.host; outlook.com; dkim=pass (signature was verified) 
header.d=indie.host;outlook.com; dmarc=bestguesspass action=none header.from=indie.host;compauth=pass reason=109 
Received-SPF: Pass (protection.outlook.com: domain of indie.host designates 195.201.199.169 as permitted sender) 
receiver=protection.outlook.com; client-ip=195.201.199.169; helo=mail.indie.host; Received: from mail.indie.host 
(195.201.199.169) by SN1NAM01FT012.mail.protection.outlook.com (10.152.64.76) with Microsoft SMTP Server 
(version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.21 via Frontend Transport; Wed, 28 Apr 2021 
19:14:01 + X-IncomingTopHeaderMarker: 
OriginalChecksum:3B9969F29DB8F8B497A9C9FFAFC66A0AE4C6537955A953653217568EFEB280B5;UpperCasedChecksum:57C883C4E156BE8B2C54F046D8E4C851D632AA891995B9759433B004C2A0F949;SizeAsReceived:1078;Count:11 
Received: from authenticated-user (mail.indie.host

Re: [mailop] Microsoft Consumer Email Deliverability Issue

2021-05-01 Thread Scott Mutter via mailop 
The fact that filling out their support ticket does nothing except generate
canned responses and that you have to come here to Mailops to get any
movement on a blocked IP address or blocked server - you would think that
that would tell Microsoft something about how ineffective their support
ticket system is.  (But as others have said, they don't really care).



On Sat, May 1, 2021 at 12:28 PM André Peters via mailop 
wrote:

> I can only agree. Using Outlook means check your junk for important mail
> and find a lot of trash in your inbox.
>
> We have moved countless new customers away from Outlook because of this
> issue. I don't know why they don't care. Really.
>
>
> > Am 01.05.2021 um 18:55 schrieb Matt Corallo via mailop <
> mailop@mailop.org>:
> >
> > If you're a small-scale sender, this is just the way it goes with
> Outlook.com - SNDS doesn't do anything except provide you %s, and because
> the number of emails from small-scale senders is so low (and the
> "customers" here don't even pay for the service), Microsoft isn't
> incentivized to fix the issue. The usual "if you're using
> outlook.com/hotmail and don't check your junk folder regularly, you're
> missing messages" rule applies.
> >
> > If you're in the very-small-scale sender club SNDS doesn't even show you
> % mails that went to spam, and exists purely to inform you that your IPs
> "have normal status" despite all the mail from them going direct to Junk
> (and all the headers, like you mentioned, showing scores of
> PCL=2/SCL=0/BCL=0).
> >
> > Worse, they haven't correctly resolved SPF/DKIM DNS records for many
> months (despite sending and receiving DNS queries for the associated
> records)[1], spuriously failing messages that others accept without issue.
> >
> > [1]
> https://techcommunity.microsoft.com/t5/outlook/received-spf-temperror-protection-outlook-com-error-in/m-p/1801696
> >
> > Matt
> >
> >> On 4/29/21 20:26, Robert Schoneman via mailop wrote:
> >> We're having issues sending order confirmations from our event
> ticketing system to users of Microsoft's consumer email services (Outlook,
> Hotmail, Live, MSN). The order confirmations are being sent to Junk. Some
> details are below this paragraph. I've communicated with Microsoft's
> "Outlook.com Deliverability Support Team" and while they were very
> responsive, unfortunately we hit a roadblock. They wanted us to enroll in
> JMRP and SNDS. Microsoft's JMRP system requires enrollment in SNDS.
> However, to enroll in SNDS requires verifying ownership of the sending
> IP's. We don't own them. Our event ticketing system vendor who does hasn't
> been helpful. We own the sending domain.
> >>  * SPF, DKIM, DMARC are all good and show as "pass" in the email
> headers of messages sent to junk.
> >>  * Sending IP's have the correct PTR records.
> >>  * Looking at the headers of a message sent to Junk, I see that our PCL
> = 2, SCL = 0 and BCL = 0.
> >>  * MS confirmed our sending IP's  and domain aren't the issue: "We were
> unable to identify anything on our side that
> >>would prevent your mail from reaching Outlook.com customers."
> >>  * MS did however determine that "messages are being filtered (i.e.
> sent to the Junk folder) based on the
> >>recommendations of the SmartScreen Filter."
> >>  * Email messages from the same sending domain and IP's, using the same
> address, which are other than order
> >>confirmations (reports, for example) deliver to my Outlook.com email
> address' Inbox without issue.
> >>  * The offending emails have
> >>  o No attachments
> >>  o One image stored on the same domain the message is sent from
> >>  o No links
> >>  o No card info
> >>  o A name and email address matching the recipient
> >>  * All emails are sent from a valid address and all NDRs/bounces are
> resolved.
> >>  * No marketing or bulk mail is sent from the domain.
> >>  * The same emails sent to Google, AOL, Yahoo deliver without issue.
> >> I'm out of ideas here and would welcome any help on or off list.  Our
> concern is if we can’t deliver an order confirmation to our customers who
> use these email services, we’ll also have issues delivering their
> electronic tickets.
> >> Robert Schoneman | Director of IT
> >> *Blumenthal Performing Arts*
> >> ___
> >> 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
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Haraka status? Exim the only choice? (v Postfix)

2021-05-01 Thread Vsevolod Stakhov via mailop 
On 01/05/2021 10:09, Thomas Walter via mailop wrote:
> 
> 
> On 01.05.21 09:05, Chris via mailop wrote:
>> Heh.  You've never used Qpsmtpd or Haraka, I can tell.  Haraka and
> 
> Nope. Didn't have to. That's why I was curious about use cases that were
> not possible with the more common MTAs.
> 
>> qpsmtpd are basically skeletons where you can insert plugins to
>> do/redefine anything you want pre/during/post any step of SMTP.  Want to
>> extend/redefine SMTP?  Sure.  Parallelize queries to any kind of
>> database?  Fine.  Regexp subjects and programmatically blackhole, nuke,
>> reject or temp?  Fine.  Skip steps when you've already decided you don't
>> want it?  Fine.
> 
> So, like the basic Postfix skeleton that comes fully assembled and is
> not missing its fingers? ;-)
> 
> Don't like the smtpd? You can swap it with anything else, can't you?
> AFAIK the interface between postfix's modules are all well defined?
> 
> Yes, of course that's not an easy task to do, but it doesn't sound like
> there is a lot less of coding for Qpsmtpd or Haraka either?
> 
> I have scripted my own little policy daemon for postfix in PHP to do
> some basic checks and rate limiting. That doesn't give me access to the
> raw smtp data, but to a whole lot of data from it
> 
> Rspamd seems to get enough data from postfix's milter interface to do
> proper and fast antispam filtering and you can extend that with all
> kinds of LUA functions. Yes, that's not postfix, but in a way, it's just
> a plugin like the others need too?

I can only add here that Rspamd can do much more things via the milter
interface than just being a spam filter: add or remove headers, e.g. add
DKIM/ARC signatures, modify message, e.g. add a footer [1], or even
remove suspicious attachments. All these functions are just not working
with Exim as it does not support neither milter nor the proper Rspamd
integration.

On the other hand, I can clearly see that Exim can also do many things
internally (for example, more sophisticated email routing) that are
literally impossible to inject or implement via the milter interface
(apart from adding/removing recipients).

Nonetheless, I would still recommend Postfix as MTA unless you have
strong preferences to something else.

[1] - https://gist.github.com/vstakhov/3dda60a5638a6aefd454973bd687fc21

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

Re: [mailop] Microsoft Consumer Email Deliverability Issue

2021-05-01 Thread Pierre Ozoux via mailop 

Hi!

(I'm new here, so if I'm doing mistakes, do not hesitate to tell me with 
MP, or public, I'd like to respect the community)



We are a small provider based in France ( https://indiehosters.net ) and 
we have all in place (DMARC, DKIM, PTR, SNDS, JMRP, and a really strict SPF)


Since a year, we are marked as spam in Microsoft and it is painful.


We are offering a free software alternative as a service for people that 
don't know much about tech, and before we were offering a Nextcloud + 
email + domain to people, but since a year we stopped offering email. 
Just because of that, we don't feel comfortable.


(and yesterday a customer canceled because of that issue :/ )


I think we tried everything, maybe not yet the outbound rate limiting. 
It is my next step. Do you think it will help?



We also use hetzner, I guess their IP range doesn't have a good 
reputation, but we have this IP since more than a year now. Do you have 
a recommendation for a provider that would have a better reputation?



I'm also planning on asking all my friends with outlook account to mark 
my emails as non spam, maybe it will help the algorithm?



When I read the answer of microsoft support, I feel like in the process 
of Kafka, I'm being accused of wrong doing, and I don't know why..


If the big tech want to push AI, I think they have to polish the user 
experience right now, but currently, it is sending the really wrong 
signal I'd say..



Here is the snippet:


8<-

We have reviewed your IP(s) (195.201.199.169) and determined that 
messages are being filtered (i.e. sent to the Junk folder) based on the 
recommendations of the SmartScreen® Filter.


Email filtering is based on many factors, but primarily it's due to mail 
content and recipient interaction with that mail. Because of the 
proprietary nature of SmartScreen® and because SmartScreen® Filter 
technology is always adapting and learning more about what is and isn't 
unwanted mail, it is not possible for us to offer specific advice about 
improving your mail content. However, in general SmartScreen® Filter 
evaluates specific words or characteristics from each e-mail message and 
weights them, based on their likelihood to indicate that a message is 
unwanted or legitimate mail.


Unfortunately, after reviewing the information you provided and in 
compliance with our mail policies, we are unable to offer immediate 
mitigation for your deliverability issue. However, we have some specific 
recommendations for you to consider that can help you to improve 
deliverability over time.


-->8--



If it can help identify the issue here is one header of an email marked 
as spam:


8<-

Received: from SN1NAM01HT088.eop-nam01.prod.protection.outlook.com 
(2603:10d6:1:13::14) by SC1PR80MB5840.lamprd80.prod.outlook.com with 
HTTPS via SC1PR80CA0111.LAMPRD80.PROD.OUTLOOK.COM; Wed, 28 Apr 2021 
21:14:08 + Received: from 
SN1NAM01FT012.eop-nam01.prod.protection.outlook.com (10.152.64.54) by 
SN1NAM01HT088.eop-nam01.prod.protection.outlook.com (10.152.64.185) with 
Microsoft SMTP Server (version=TLS1_2, 
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.21; Wed, 28 
Apr 2021 19:14:02 + Authentication-Results: spf=pass (sender IP is 
195.201.199.169) smtp.mailfrom=indie.host; outlook.com; dkim=pass 
(signature was verified) header.d=indie.host;outlook.com; 
dmarc=bestguesspass action=none header.from=indie.host;compauth=pass 
reason=109 Received-SPF: Pass (protection.outlook.com: domain of 
indie.host designates 195.201.199.169 as permitted sender) 
receiver=protection.outlook.com; client-ip=195.201.199.169; 
helo=mail.indie.host; Received: from mail.indie.host (195.201.199.169) 
by SN1NAM01FT012.mail.protection.outlook.com (10.152.64.76) with 
Microsoft SMTP Server (version=TLS1_2, 
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.21 via 
Frontend Transport; Wed, 28 Apr 2021 19:14:01 + 
X-IncomingTopHeaderMarker: 
OriginalChecksum:3B9969F29DB8F8B497A9C9FFAFC66A0AE4C6537955A953653217568EFEB280B5;UpperCasedChecksum:57C883C4E156BE8B2C54F046D8E4C851D632AA891995B9759433B004C2A0F949;SizeAsReceived:1078;Count:11 
Received: from authenticated-user (mail.indie.host [195.201.199.169]) 
(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) 
key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest 
SHA256) (No client certificate requested) by mail.indie.host (Postfix) 
with ESMTPSA id 472B63104A3 for ; Wed, 28 Apr 
2021 19:14:00 + (UTC) DKIM-Signature: v=1; a=rsa-sha256; 
c=simple/simple; d=indie.host; s=mail; t=1619637240; 
bh=4xTo9NybVTJVLznlhtmKky7A4ycQONri6kUHBVV8KvQ=; 
h=To:From:Subject:Date:From; 
b=hbvVu70PxQFCBUht1XyBDbJ6ayu9t+SK4UOzTrV+W4+B7mcS8wwVgbrwDPHxTeM5E 
MoFADifrRLBqM/UYmrDdhaZKVRfRAMGAQRllfH7Nq5ZcWXOT571C9YIn62pI7B79kU 
0L9IhszaAikKMQkaiSsFeYIHQCT5wkc3uYhiNQR4= To: Pierre Ozoux 
 From: Contact  Subject: 
Hello! Message-ID:  
Date: Wed, 28 Apr 2021 21:13:54 +0200 Content-Type:

Re: [mailop] Mailfront, was Haraka status? Exim the only choice? (v Postfix)

2021-05-01 Thread John Levine via mailop 
It appears that Chris via mailop  said:
>There's a third called "mailfront" that uses plugin C
>modules.  I know almost nothing more about it, other than its similar in
>intent/architecture.  I think the community surrounding it is even smaller.
>
>Still running it John?

Yup, works great.  It's written by Bruce Guenther who also wrote the fairly 
popular
bglibs and other packages.  It's not threaded, rather it's intended to be run 
from
tcpserver, new process for every message which starts up, loads all the plugins
and handles an SMTP session.  It seems quite fast although my system is pretty 
small.
With 100 simultaneous sessions there's no perceptible load.  It comes with 
backend
modules to hand mail to qmail or to put it in a queue directory but having 
written
a bunch of plugins I can say it'd be easy to write a back end to hand mail to
whatever you want to hand it to.  If the plugin loading turned out to be slow it
wouldn't be hard to restructure it to load the plugins once and then fork off 
processes
as connections arrive but it's fast enough nobody's bothered.

I've written plugins to add STARTTLS with SNI (that one got incorporated into 
the
mailfront distribution), do SPF, DKIM, DMARC and ARC checks, log message 
metadata
in a mysql database, redirect mail that's hopelessly spammy into a sump process 
rather
than qmail as well as some exotic ones like the fake SMTP AUTH that lets you 
log in
with any user/pw but then puts the message into the sump.  There sure are a lot 
of
persistent password guessing bots.

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

Re: [mailop] Mailfront, was Haraka status? Exim the only choice? (v Postfix)

2021-05-01 Thread John Levine via mailop 
It appears that Chris via mailop  said:
>There's a third called "mailfront" that uses plugin C
>modules.  I know almost nothing more about it, other than its similar in
>intent/architecture.  I think the community surrounding it is even smaller.
>
>Still running it John?

Yup, works great.  It's written by Bruce Guenther who also wrote the fairly 
popular
bglibs and other packages.  It's not threaded, rather it's intended to be run 
from
tcpserver, new process for every message which starts up, loads all the plugins
and handles an SMTP session.  It seems quite fast although my system is pretty 
small.
With 100 simultaneous sessions there's no perceptible load.  It comes with 
backend
modules to hand mail to qmail or to put it in a queue directory but having 
written
a bunch of plugins I can say it'd be easy to write a back end to hand mail to
whatever you want to hand it to.  If the plugin loading turned out to be slow it
wouldn't be hard to restructure it to load the plugins once and then fork off 
processes
as connections arrive but it's fast enough nobody's bothered.

I've written plugins to add STARTTLS with SNI (that one got incorporated into 
the
mailfront distribution), do SPF, DKIM, DMARC and ARC checks, log message 
metadata
in a mysql database, redirect mail that's hopelessly spammy into a sump process 
rather
than qmail as well as some exotic ones like the fake SMTP AUTH that lets you 
log in
with any user/pw but then puts the message into the sump.  There sure are a lot 
of
persistent password guessing bots.

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

Re: [mailop] Microsoft Consumer Email Deliverability Issue

2021-05-01 Thread André Peters via mailop 
I can only agree. Using Outlook means check your junk for important mail and 
find a lot of trash in your inbox. 

We have moved countless new customers away from Outlook because of this issue. 
I don't know why they don't care. Really.


> Am 01.05.2021 um 18:55 schrieb Matt Corallo via mailop :
> 
> If you're a small-scale sender, this is just the way it goes with 
> Outlook.com - SNDS doesn't do anything except provide you %s, and because the 
> number of emails from small-scale senders is so low (and the "customers" here 
> don't even pay for the service), Microsoft isn't incentivized to fix the 
> issue. The usual "if you're using outlook.com/hotmail and don't check your 
> junk folder regularly, you're missing messages" rule applies.
> 
> If you're in the very-small-scale sender club SNDS doesn't even show you % 
> mails that went to spam, and exists purely to inform you that your IPs "have 
> normal status" despite all the mail from them going direct to Junk (and all 
> the headers, like you mentioned, showing scores of PCL=2/SCL=0/BCL=0).
> 
> Worse, they haven't correctly resolved SPF/DKIM DNS records for many months 
> (despite sending and receiving DNS queries for the associated records)[1], 
> spuriously failing messages that others accept without issue.
> 
> [1] 
> https://techcommunity.microsoft.com/t5/outlook/received-spf-temperror-protection-outlook-com-error-in/m-p/1801696
> 
> Matt
> 
>> On 4/29/21 20:26, Robert Schoneman via mailop wrote:
>> We're having issues sending order confirmations from our event ticketing 
>> system to users of Microsoft's consumer email services (Outlook, Hotmail, 
>> Live, MSN). The order confirmations are being sent to Junk. Some details are 
>> below this paragraph. I've communicated with Microsoft's "Outlook.com 
>> Deliverability Support Team" and while they were very responsive, 
>> unfortunately we hit a roadblock. They wanted us to enroll in JMRP and SNDS. 
>> Microsoft's JMRP system requires enrollment in SNDS. However, to enroll in 
>> SNDS requires verifying ownership of the sending IP's. We don't own them. 
>> Our event ticketing system vendor who does hasn't been helpful. We own the 
>> sending domain.
>>  * SPF, DKIM, DMARC are all good and show as "pass" in the email headers of 
>> messages sent to junk.
>>  * Sending IP's have the correct PTR records.
>>  * Looking at the headers of a message sent to Junk, I see that our PCL = 2, 
>> SCL = 0 and BCL = 0.
>>  * MS confirmed our sending IP's  and domain aren't the issue: "We were 
>> unable to identify anything on our side that
>>would prevent your mail from reaching Outlook.com customers."
>>  * MS did however determine that "messages are being filtered (i.e. sent to 
>> the Junk folder) based on the
>>recommendations of the SmartScreen Filter."
>>  * Email messages from the same sending domain and IP's, using the same 
>> address, which are other than order
>>confirmations (reports, for example) deliver to my Outlook.com email 
>> address' Inbox without issue.
>>  * The offending emails have
>>  o No attachments
>>  o One image stored on the same domain the message is sent from
>>  o No links
>>  o No card info
>>  o A name and email address matching the recipient
>>  * All emails are sent from a valid address and all NDRs/bounces are 
>> resolved.
>>  * No marketing or bulk mail is sent from the domain.
>>  * The same emails sent to Google, AOL, Yahoo deliver without issue.
>> I'm out of ideas here and would welcome any help on or off list.  Our 
>> concern is if we can’t deliver an order confirmation to our customers who 
>> use these email services, we’ll also have issues delivering their electronic 
>> tickets.
>> Robert Schoneman | Director of IT
>> *Blumenthal Performing Arts*
>> ___
>> 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] Microsoft Consumer Email Deliverability Issue

2021-05-01 Thread Matt Corallo via mailop 
If you're a small-scale sender, this is just the way it goes with Outlook.com - SNDS doesn't do anything except provide 
you %s, and because the number of emails from small-scale senders is so low (and the "customers" here don't even pay for 
the service), Microsoft isn't incentivized to fix the issue. The usual "if you're using outlook.com/hotmail and don't 
check your junk folder regularly, you're missing messages" rule applies.


If you're in the very-small-scale sender club SNDS doesn't even show you % mails that went to spam, and exists purely to 
inform you that your IPs "have normal status" despite all the mail from them going direct to Junk (and all the headers, 
like you mentioned, showing scores of PCL=2/SCL=0/BCL=0).


Worse, they haven't correctly resolved SPF/DKIM DNS records for many months (despite sending and receiving DNS queries 
for the associated records)[1], spuriously failing messages that others accept without issue.


[1] 
https://techcommunity.microsoft.com/t5/outlook/received-spf-temperror-protection-outlook-com-error-in/m-p/1801696

Matt

On 4/29/21 20:26, Robert Schoneman via mailop wrote:
We're having issues sending order confirmations from our event ticketing system to users of Microsoft's consumer email 
services (Outlook, Hotmail, Live, MSN). The order confirmations are being sent to Junk. Some details are below this 
paragraph. I've communicated with Microsoft's "Outlook.com Deliverability Support Team" and while they were very 
responsive, unfortunately we hit a roadblock. They wanted us to enroll in JMRP and SNDS. Microsoft's JMRP system 
requires enrollment in SNDS. However, to enroll in SNDS requires verifying ownership of the sending IP's. We don't own 
them. Our event ticketing system vendor who does hasn't been helpful. We own the sending domain.


  * SPF, DKIM, DMARC are all good and show as "pass" in the email headers of 
messages sent to junk.
  * Sending IP's have the correct PTR records.
  * Looking at the headers of a message sent to Junk, I see that our PCL = 2, 
SCL = 0 and BCL = 0.
  * MS confirmed our sending IP's  and domain aren't the issue: "We were unable 
to identify anything on our side that
would prevent your mail from reaching Outlook.com customers."
  * MS did however determine that "messages are being filtered (i.e. sent to 
the Junk folder) based on the
recommendations of the SmartScreen Filter."
  * Email messages from the same sending domain and IP's, using the same 
address, which are other than order
confirmations (reports, for example) deliver to my Outlook.com email 
address' Inbox without issue.
  * The offending emails have
  o No attachments
  o One image stored on the same domain the message is sent from
  o No links
  o No card info
  o A name and email address matching the recipient
  * All emails are sent from a valid address and all NDRs/bounces are resolved.
  * No marketing or bulk mail is sent from the domain.
  * The same emails sent to Google, AOL, Yahoo deliver without issue.

I'm out of ideas here and would welcome any help on or off list.  Our concern is if we can’t deliver an order 
confirmation to our customers who use these email services, we’ll also have issues delivering their electronic tickets.


Robert Schoneman | Director of IT

*Blumenthal Performing Arts*


___
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] Haraka status? Exim the only choice? (v Postfix)

2021-05-01 Thread Matthias Leisi via mailop 

> I used Postfix along time but my experience is that it is incredible 
> difficult to implement custom logic especially across the different 
> binaries/processes it uses to fulfil a mail delivery transaction. Its 
> designed in the "unix philosophy" and has good performance - great but 
> Postfix devs normally react hostile if asked for advanced features that 
> require tracking meta-information about messages across Postfix processes. 
> Its only the RFC compliant mail message state that persisting through the 
> entire transaction, nothing more. Milters can be injected but have 
> limitations and I get headaches from the configuration system. I shouldn't 
> complain too hard tho, because I'm grateful for how solid and secure and 
> bulletproof it has been. Thank you team Postfix.
> 
> But I want more power and customization not only generic mailserver.

For sticking with Postfix, have a look at https://fuglu.org/ 


— Matthias

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

Re: [mailop] Haraka status? Exim the only choice? (v Postfix)

2021-05-01 Thread Thomas Walter via mailop 


On 01.05.21 09:05, Chris via mailop wrote:
> Heh.  You've never used Qpsmtpd or Haraka, I can tell.  Haraka and

Nope. Didn't have to. That's why I was curious about use cases that were
not possible with the more common MTAs.

> qpsmtpd are basically skeletons where you can insert plugins to
> do/redefine anything you want pre/during/post any step of SMTP.  Want to
> extend/redefine SMTP?  Sure.  Parallelize queries to any kind of
> database?  Fine.  Regexp subjects and programmatically blackhole, nuke,
> reject or temp?  Fine.  Skip steps when you've already decided you don't
> want it?  Fine.

So, like the basic Postfix skeleton that comes fully assembled and is
not missing its fingers? ;-)

Don't like the smtpd? You can swap it with anything else, can't you?
AFAIK the interface between postfix's modules are all well defined?

Yes, of course that's not an easy task to do, but it doesn't sound like
there is a lot less of coding for Qpsmtpd or Haraka either?

I have scripted my own little policy daemon for postfix in PHP to do
some basic checks and rate limiting. That doesn't give me access to the
raw smtp data, but to a whole lot of data from it

Rspamd seems to get enough data from postfix's milter interface to do
proper and fast antispam filtering and you can extend that with all
kinds of LUA functions. Yes, that's not postfix, but in a way, it's just
a plugin like the others need too?

Regards,
Thomas Walter

-- 
Thomas Walter
Datenverarbeitungszentrale

FH Münster
- University of Applied Sciences -
Corrensstr. 25, Raum B 112
48149 Münster

Tel: +49 251 83 64 908
Fax: +49 251 83 64 910
www.fh-muenster.de/dvz/



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Haraka status? Exim the only choice? (v Postfix)

2021-05-01 Thread Heiko Schlittermann via mailop 
I forgot the "selling point" that hooked me: The specification.

   http://exim.org/exim-html-current/doc/html/spec_html/index.html

It simply contains everything you need. But the reader has to
understand, that setup/operation of mail server can be a complex task.

As you're on *this* mailop list, I assume that you're aware of that fact ;)
Someone compared Postfix and Exim like PlayMobil and Lego.

Again, I'm biased.

-- 
Heiko


signature.asc
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Haraka status? Exim the only choice? (v Postfix)

2021-05-01 Thread Heiko Schlittermann via mailop 
Hi Rob,

I'm biased as part of the Exim development team.

Exim 
- is actively maintained
- has a huge user base
- provides more flexibility than other MTA I'm aware of (but, this is
  *my* PoV)

> That mean Exim is the only real choice? It was a good laughing from this
> recent mailop post about Exim vulnerability and I see Exim gets regular
> vulnerabilities.
> https://www.mail-archive.com/mailop@mailop.org/msg12993.html
> 
> But it look like Exim have infinite customization possibility which should
> help me. I guessing that one must accept more vulnerabilities for having
> more power flexibility that Exim gives.

A huge number of major companies and individual users run Exim systems
faced to the internet. Apart from the known and publicly communicated
vulnerabilities we do not know of any security issues in the wild.

(I'm not talking about issues introduced by unfortunate configuration -
the flexible configuration gives you the power to kill yourself. But
even here we're working (recently we introduced the concept of "tainted"
data)).

You're invited to use Exim. And you are introduced to contribute.

Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann
--
 SCHLITTERMANN.de  internet & unix support -
 Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
 gnupg encrypted messages are welcome --- key ID: F69376CE -


signature.asc
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Haraka status? Exim the only choice? (v Postfix)

2021-05-01 Thread Chris via mailop 
Heh.  You've never used Qpsmtpd or Haraka, I can tell.  Haraka and
qpsmtpd are basically skeletons where you can insert plugins to
do/redefine anything you want pre/during/post any step of SMTP.  Want to
extend/redefine SMTP?  Sure.  Parallelize queries to any kind of
database?  Fine.  Regexp subjects and programmatically blackhole, nuke,
reject or temp?  Fine.  Skip steps when you've already decided you don't
want it?  Fine.

It was so swiss army knife it doesn't even know how to do AUTH, MXing
and barely outbound SMTP. The latest version may not even be able to do
TLS anymore either. You have to write those bits yourself.

Think of qpsmtpd and harakka as postfix's smtp-sink with plugin capability.

[I've played a lot with smtp-sink too - makes a great dumb trap if you
hack it a bit to save the right bits in a spool directory.]

They really shine in making spamtraps that analyse what they receive,
communicate with other packages, other systems, generate dataflows of
anything you want, trivially implement new filtering methods, all in
real time.

I once asked one of the postfix gurus - not Wietse, but one of the few
secondary ones if I could do something really simple that I'd been doing
for years in qpsmtpd.  How simple?  I wanted to expose the RAW SMTP
transactions to a milter or some other plugin.  After asking *why* I
wanted it, he said "leave me an hour to think and I'll let you know".

Came back in an hour, and what did he say?  "We'd have to rewrite the
core, sorry".  Oops.

The ONLY "ordinary" MTA I know of that can do this simple task is EXIM.

Qpsmtpd lost a lot when its major contributor left to invent Harraka.  A
lot of code when stale and functionality/performance was lost.  The
version core I'm using (at one time on 60+ MTAS) is probably over a
decade old.

The big problem with qpsmtpd is that it was written so "open", and had
so much configurability, that there never was a distributed unified set
of plugins that could play nicely and do anything much more than
stuffing what it didn't rejee into qmail queues.  I always had to write
my own from scratch.  Making it harder is that the documentation was
scattered, disconnected, incomplete, and nobody kept it up to date.
Nobody was herding the cats.  As I understand it, the Haraka community
is much the same.

Which means *steep* learning curves that can't rely on documentation.  I
really don't know anybody still running Qpsmtpd other than me.  Haraka
still has some specialized commercial users too.

Don't get me wrong, they both have strong, but small and closed
communities, and harakka is more modern.  But they're almost all doing
extremely specialized things, and don't talk a lot.  Never did.

qmsmtpd and haraka basically do the same thing, one is in Perl, the
other in Java.  You'd be surprised how fast they are when configured
properly.  There's a third called "mailfront" that uses plugin C
modules.  I know almost nothing more about it, other than its similar in
intent/architecture.  I think the community surrounding it is even smaller.

Still running it John?

I would recommend against using *any* of these if you're trying for a
high performance fairly normal "modern" MTA and don't want to spend a
few years learning their guts and coding custom plugins for almost
everything. None of them are full MTAs, they're most used in production
environments as front ends to real MTAs.  I used them standalone as
traps, and production server front ends relaying "clean" inbound email
to something else like postfix or sendmail.


On 2021-05-01 2:13 a.m., Thomas Walter via mailop wrote:
> Hello MRob,
> 
> On 01.05.21 05:18, MRob via mailop wrote:
>> I used Postfix along time but my experience is that it is incredible
>> difficult to implement custom logic especially across the different
>> binaries/processes it uses to fulfil a mail delivery transaction. Its
>> designed in the "unix philosophy" and has good performance - great but
>> Postfix devs normally react hostile if asked for advanced features that
>> require tracking meta-information about messages across Postfix
>> processes. Its only the RFC compliant mail message state that persisting
>> through the entire transaction, nothing more. Milters can be injected
>> but have limitations and I get headaches from the configuration system.
>> I shouldn't complain too hard tho, because I'm grateful for how solid
>> and secure and bulletproof it has been. Thank you team Postfix.
> While I understand your frustration, I wonder what "advanced feature"
> you are looking for. In the end you can override each and every single
> Postfix element or how they interact. It's that flexibility that gives
> me most of my headaches.
> 
> Regards
> Thomas Walter
> 
> 
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
> 

___
mailop mailing list
mailop@mailop.org

Re: [mailop] Haraka status? Exim the only choice? (v Postfix)

2021-05-01 Thread Thomas Walter via mailop 
Hello MRob,

On 01.05.21 05:18, MRob via mailop wrote:
> I used Postfix along time but my experience is that it is incredible
> difficult to implement custom logic especially across the different
> binaries/processes it uses to fulfil a mail delivery transaction. Its
> designed in the "unix philosophy" and has good performance - great but
> Postfix devs normally react hostile if asked for advanced features that
> require tracking meta-information about messages across Postfix
> processes. Its only the RFC compliant mail message state that persisting
> through the entire transaction, nothing more. Milters can be injected
> but have limitations and I get headaches from the configuration system.
> I shouldn't complain too hard tho, because I'm grateful for how solid
> and secure and bulletproof it has been. Thank you team Postfix.
While I understand your frustration, I wonder what "advanced feature"
you are looking for. In the end you can override each and every single
Postfix element or how they interact. It's that flexibility that gives
me most of my headaches.

Regards
Thomas Walter

-- 
Thomas Walter
Datenverarbeitungszentrale

FH Münster
- University of Applied Sciences -
Corrensstr. 25, Raum B 112
48149 Münster

Tel: +49 251 83 64 908
Fax: +49 251 83 64 910
www.fh-muenster.de/dvz/



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop