Re: [mailop] Gmail rejects multiple From:'s. Who else?

[Franck Martin via mailop]

Hi,

I checked it way back, and nearly all the cases were due to configuration 
errors on the sender part.

It is not a feature that is actively used in the wild. I don’t know of any 
email client that allows you to do that. So someone needs to craft a specific 
message and inject it.

Now, when DMARC was brought in, having 2 different domains in the RFC 5322 
from: does not allow DMARC to function. Technically, DMARC can work if all the 
domains in the RFC5322 from are the same, but I guess it is just easier to 
reject such message as the impact is close to zero and often multiple From is 
just a strong signal of badness/spam.

If you know of an active useful use case, I’m curious.

From: mailop  on behalf of Alessandro Vesely via 
mailop 
Date: Monday, December 13, 2021 at 09:23
To: mailop 
Subject: [mailop] Gmail rejects multiple From:'s. Who else?
Hi,

I assume everybody knows that RFC 5322 allows multiple mailboxes in the From: 
field.  This feature existed in RFC822 already.  I think it is to be used for 
those cases where multiple persons are authoring a message, albeit adding the 
list of coauthors is usually not done.  This message is an example.  How many 
rejects does it yield?

Gmail reacts like so:

Action: failed
Status: 5.0.0
Remote-MTA: dns; gmail-smtp-in.l.google.com [108.177.119.27]
Diagnostic-Code: smtp; 550-5.7.1 [192.0.2.4  13] Messages with multiple 
addresses in From:
 550 5.7.1 header are not accepted. do22si22787062ejc.211 - gsmtp


Is it customary to reject messages with multiple addresses in From:?  Why?


Best
Ale
--






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

Re: [mailop] Dealing with "454 TLS not available issues" (Aruba.it)

[Franck Martin via mailop]

Seems to me the system is may be trying to verify the certificate? It may
be checking the revoking list?

But yes I would try to contact Aruba to get some info, may be someone on
the list has a contact there?

On Mon, Jan 23, 2017 at 11:42 AM, Brandon Long via mailop  wrote:

> Note that information about Google is about 3 years out of date, we no
> longer fall back to unencrypted.
>
> Your best bet for important domains you care about it to try and contact
> their admins to fix it.
>
> Other than that, it's basically up to your policies what to do... well,
> and what your software can do.
>
> For us, the numbers were small enough to not be worth potentially sending
> the mail in the clear.
>
> Brandon
>
> On Jan 23, 2017 10:21 AM, "Stefano Bagnara"  wrote:
>
>> We recently enabled starttls to every destination (announcing the
>> starttls extension).
>>
>> We now see a lot of "454 4.3.3 TLS not available due to temporary reason"
>> in reply to the STARTTLS by a big B2B italian provider named Aruba. We
>> usually are able to send the email after 2-3-5 attempts, so this is not
>> causing "failures" but mainly delay, but randomness could even cause
>> permanent failures.
>>
>> Now, I read a forum where someone said Google try TLS delivery for 1 day,
>> then they switch to plain text delivery if the delivery didn't happen in
>> the first 24 hours.
>>
>> What do other senders do? Is this "try TLS for a while then switch to
>> plain text" a best practice or just something "invented" by Google? Or do
>> you use whitelist/blacklist in order to decide valid TLS destinations?
>>
>> I also have similar messages by other targets, but thet are very low
>> volume, so I didn't investigate them:
>> - 454 4.7.0 TLS not available due to local problem
>> - 454 4.3.0 TLS not available due to local problem
>> - 454 TLS currently unavailable
>> - 454 TLS missing certificate: error:02001002:system library:fopen:No
>> such file or directory (#4.3.0) )
>>
>> Stefano
>>
>> PS: this is my first post and www mailop org is not working right now so
>> I've not been able to check the "posting guidelines" to see if this kind of
>> message is allowed or not in this list.
>>
>> ___
>> mailop mailing list
>> mailop@mailop.org
>> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>>
>>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Trying to work out cause of "Certificate rejected over TLS. (unknown protocol)" error

[Franck Martin via mailop]

You may want to use this tool on your mail server(so it picks up the same
openssl version) to check what cyphers the mil server accepts:
https://testssl.sh/

Beware, I believe one connection is open for each cypher tested, the client
offers only one cypher and see if the connection completes...



On Mon, Jan 9, 2017 at 6:48 AM, Graeme Fowler 
wrote:

> On 9 Jan 2017, at 14:08, Franck Martin via mailop 
> wrote:
>
> Often, it is a problem of finding an acceptable cypher to both parties...
>
>
> ...after...
>
> On Mon, Jan 9, 2017 at 4:21 AM, Robert Mueller  wrote:
>>
>> So it turns out we'd actually encountered this problem before (Oct
>> 2015), and had put a work around in place at the time. It appears that
>> us.af.mil servers were having problems connecting to our postfix
>> instances and at the time couldn't work out what the obvious reason was
>> so I had added this to our postfix config.
>
>
> They're finding a cipher they don't like - so far as I can ascertain, your
> host is offering an RC4 based cipher. If they're .mil, as you mention, then
> their cipher compatibility list will likely be small and hard (so to
> speak). I can't speak for why they'd not connect to you as a result, that's
> up to them.
>
> https://ssl-tools.net/mailservers/mx1.messagingengine.com
>
> Graeme
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Trying to work out cause of "Certificate rejected over TLS. (unknown protocol)" error

[Franck Martin via mailop]

The negotiation of STARTTLS is done in clear, so a packet capture will tell
you where the problem is... Wireshark usually explains well what options
are in the packets...

Often, it is a problem of finding an acceptable cypher to both parties...

Finally, make sure your firewall is not messing up with SMTP packets...

On Mon, Jan 9, 2017 at 4:21 AM, Robert Mueller  wrote:

>
> > We've suddenly had a couple of reports from users about people sending
> > to them (e.g. sending from a remote service to our servers) failing and
> > bouncing with the error message:
> >
> > Certificate rejected over TLS. (unknown protocol)
>
> Just to update with more information.
>
> So it turns out we'd actually encountered this problem before (Oct
> 2015), and had put a work around in place at the time. It appears that
> us.af.mil servers were having problems connecting to our postfix
> instances and at the time couldn't work out what the obvious reason was
> so I had added this to our postfix config.
>
> main.cf
> ...
> # Disable starttls for some problematic hosts
> smtpd_discard_ehlo_keyword_address_maps =
> cidr:/etc/postfix/access_client-helo_keyword.cidr
>
> access_client-helo_keyword.cidr
> # us.af.mil has TLS problems. IPs taken from SPF record (e.g. dig
> us.af.mil TXT)
> 132.3.0.0/16 starttls
> ...
> 131.15.70.0/24 starttls
>
> It appears recently they must have added additional servers, since their
> SPF records have changed. Adding these:
>
> +131.9.253.0/24 starttls
> +131.27.1.0/24 starttls
>
> Fixed the problem.
>
> Ideally I'd like to actually work out what's causing the sending servers
> to fail with our TLS configuration, but it's a bit of work I haven't had
> time for, thus this work around for now.
>
> --
> Rob Mueller
> r...@fastmail.fm
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Anyone from Yahoo - icmpv6 filtering breaks login.yahoo.com MTU detection

[Franck Martin via mailop]

It is also common when people convert their ACL from IPv4 to IPv6 to forget
to add a rule of PTB in their IPv6 ACLs...

I would also suggest to use tracepath(6) for debugging, as it factors the
port you want to reach and will try to detect the pmtu. You may find where
the packet gets dropped this way.

On Mon, Nov 21, 2016 at 1:09 AM, Vladimir Dubrovin via mailop <
mailop@mailop.org> wrote:

>
> This problem is neither new nor specific to Yahoo or IPv6 and is usually
> referred as "blackhole router". ICMPv4 "Fragmentation Needed" (type 3
> code4) / ICMPv6 "Packet to Big" (type 2) *are required* for path MTU
> discovery and should never be filtered. The only reason it doesn't strike
> you with different servers is it's highly recommended for public server to
> set MaxMTU lower than 1500 (typically 1400 or so, or more exactly TCP MSS
> is usually set to corresponding value), because there is a lot of users
> with misconfigured routers and firewall.
>
>
> 18.11.2016 22:58, Carl Byington пишет:
>
> https://login.yahoo.com
>
> If you have IPv6 connectivity thru a tunnel, with a smaller MTU, that
> will fail. With a 1500 byte MTU, it works. The TCP handshake works - it
> then hangs during the TLS handshake which sends full size packets.
>
> echo -e 'GET / HTTP/1.0\n' | \
> openssl s_client -servername login.yahoo.com -ign_eof -connect \
> '[2001:4998:c:e33::50]:443'
>
> Please stop filtering icmpv6 packets going to your servers.
>
>
> > > > > ___ > 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

Re: [mailop] Microsoft Blacklisting IPs

[Franck Martin via mailop]

I would suggest you sign up for the JMRP, so you know what people are
complaining about...

On Thu, Nov 17, 2016 at 12:46 AM, Angelo Giuffrida <
angelo.giuffr...@gmail.com> wrote:

> Welcome to the fun game of Microsoft & Hotmail blocks. If you do a search
> through the list archives you'll find responses from Michael (and others)
> that will be helpful. That should provide you with some information to get
> started whilst you wait for others to reply.
>
> On Thu., 17 Nov. 2016 at 7:24 pm, Hetzner Blacklist Support <
> blackl...@hetzner.de> wrote:
>
>> Hello,
>>
>> We're currently having some major issues with our IPs being blacklisted
>> by Microsoft. I'm signed up for the SNDS and a huge amount of our IPs
>> are "blocked due to user complaints or other evidence of spamming".
>>
>> It's fairly easy to have the IPs delisted by filling out the "Sender
>> Information for Outlook.com Delivery" form that Microsoft provides.
>> However, that only allows up to a /24 to be delisted at a time, which
>> means it is going to take a very long time to delist all of our ranges.
>>
>> Also, that doesn't actually address the underlying issue. Obviously spam
>> isn't being sent from all of those IPs, but there has to be some reason
>> Microsoft is listing them all.
>>
>> Is this something anybody here has experienced? Better yet, is there
>> somebody from Microsoft who could have a quick look at this and give me
>> some insight into the underlying issue? I've been attempting to contact
>> Microsoft for a while now and only ever get canned responses (if at all).
>>
>> Any tips or help would be greatly appreciated, thanks.
>>
>> Kind regards
>>
>> Bastiaan van den Berg
>>
>> Hetzner Online GmbH
>>
>> ___
>> mailop mailing list
>> mailop@mailop.org
>> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Listbomb issue

[Franck Martin via mailop]

This document can be of use:
https://www.m3aawg.org/documents/en/maawg-vetting-best-common-practices-bcp

Also, you may want to look at e-hawk.net

On Wed, Oct 19, 2016 at 1:27 PM, Vick Khera  wrote:

> On Wed, Oct 19, 2016 at 3:35 PM, Brett Schenker 
> wrote:
> > We're currently looking to implement a combination of preventions with
> the
> > leading idea being:
> > honeypot on sign up pages + IP intelligence + email address intelligence
> +
> > coi
> >
> > The idea being the honeypot will stop some bots, the IP monitoring will
> look
> > for numerous sign ups within a short periond of time (which we currently
> do
> > for credit cards) and then also look for email addresses being signed up
> > acorss clients in a short period of time.
>
> My thought on this is that *I* cannot detect the rate of signups as
> well as reputation services can. To this end, I use the following
> algorithm on our list signup forms. The beauty of it is that you
> really only get to see the CAPTCHA if you are a trouble maker.
> Normally you will never get presented with it, so it looks like
> business as usual to everyone else. I do this test both when
> displaying the form and when processing the form, because bots never
> fetch the form itself, and humans don't want to fail a captcha they
> never saw in the first place.
>
> 1) Is the remote IP listed in CBL? Yes -> force CAPTCHA
> 2) Is the remote IP listed in CleanTalk.org/blacklists?  Yes -> force
> CAPTCHA
> 3) Is the remote IP listed in minFraud open proxies? Yes -> force CAPTCHA
>
> Then proceed with the normal signup form, which in our case is always
> COI for all customers. I do the tests in the above order, and short
> circuit once I have a positive match. Each of the three services
> catches about ⅓ of the bad actors, amazingly enough. I do the queries
> in the order of cost to me, so as to minimize how much I have to
> spend. :-)  I also cache the results.
>
> A couple of my customers have asked for 100% CAPTCHA because they
> wanted a 100% block of the bots. This mechanism I use gets close to
> 75% of them based on my testing two months ago.
>
> If you're the lucky guy who is first hit when the bots get a new IP,
> you'll be out of luck. But, if you're lower down their list, then
> likely these guys will have detected that IP by the time they get to
> you. minFraud will even notify you if they subsequently detect bot
> activity on an IP you queried, which is nice sometimes to go back and
> clean up.
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] anyone from Microsoft around ?

[Franck Martin via mailop]

As Michael says "Microsoft not Hotmail"

On Wed, Sep 21, 2016 at 2:11 PM, Renaud Allard via mailop  wrote:

>
>
> 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\;"
>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] anyone from Microsoft around ?

[Franck Martin via mailop]

Gilles,

I think you will get much background document from
https://blogs.msdn.microsoft.com/tzink/2014/12/03/using-dmarc-in-office-365/

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.

Now, mailing lists break DMARC (or DMARC break mailing lists, but let's not
get into philosophy).  There are a few options for you that are described
in: https://tools.ietf.org/html/draft-ietf-dmarc-interoperability-18

Basically what works today you can do:
-Do not break the DKIM of the poster
-Change the From: header to put the email of the list instead of the poster
-reject email from someone posting from a DMARC protected domain

There are a few things that may work tomorrow, like ARC.

As your volume is low, MS may not be able to detect it is a mailing list
and decide to overwrite the DMARC policy.

On Wed, Sep 21, 2016 at 6:56 AM, Gilles Chehade via mailop <
mailop@mailop.org> wrote:

> On Wed, Sep 21, 2016 at 01:54:43PM +, Michael Wise wrote:
> >
> > If it's Hotmail, it's almost certainly an IP specific issue. Open a
> ticket
> >
>
> ok thanks !
>
>
> > 
> > From: Gilles Chehade
> > Sent: ?9/?21/?2016 6:31 AM
> > To: Michael Wise
> > Cc: Steve Atkins; mailop org>
> > Subject: Re: [mailop] anyone from Microsoft around ?
> >
> > On Wed, Sep 21, 2016 at 01:16:47PM +, Michael Wise via mailop wrote:
> > >
> > > The headers in particular.
> >
> > sent in another mail to the thread the two pastebins
> >
> > > And is this to Hotmail, et al or Office365?
> > >
> >
> > only complaints i've received where about hotmail and this is where I
> > reproduce the issue with other members of my community right now.
> >
> > I honestly have no idea about Office365 :/
> >
> >
> >
> > > Aloha,
> > > Michael.
> > > --
> > > Sent from my Windows Phone
> > > 
> > > From: Steve Atkins
> > > Sent: ?9/?21/?2016 5:56 AM
> > > To: mailop
> > > Subject: Re: [mailop] anyone from Microsoft around ?
> > >
> > >
> > > > On Sep 21, 2016, at 4:02 AM, Gilles Chehade 
> wrote:
> > > >
> > > >
> > > > I'm wondering if there is something wrong in the format of our
> headers
> > > > and if this could affect users of our software disregarding the kind
> > > > of mails they send with it. I've been tackling this for hours before
> > > > contacting the mailing list.
> > > >
> > > > Any help would be greatly appreciated, I'm running out of ideas :-)
> > >
> > > Sharing a sample of those headers on a paste site (and maybe
> > > a protocol level trace of a failing transaction) might get you some
> > > feedback on whether anything looks off about them.
> > >
> > > Cheers,
> > >   Steve
> > >
> > >
> > > ___
> > > mailop mailing list
> > > mailop@mailop.org
> > > https://na01.safelinks.protection.outlook.com/?url=
> https%3a%2f%2fchilli.nosignal.org%2fcgi-bin%2fmailman%
> 2flistinfo%2fmailop&data=02%7c01%7cmichael.wise%40microsoft.com%
> 7c7b9c6ad2ee9b4a4e6b4f08d3e21ec293%7c72f988bf86f141af91ab2d7cd011
> db47%7c1%7c0%7c636100594149963484&sdata=XtboHW2aVAEav7gFT65xCVy%2bk%
> 2befTPXCdBNQbBIL5Zs%3d
> >
> > > ___
> > > mailop mailing list
> > > mailop@mailop.org
> > > https://na01.safelinks.protection.outlook.com/?url=
> https%3a%2f%2fchilli.nosignal.org%2fcgi-bin%2fmailman%
> 2flistinfo%2fmailop&data=02%7c01%7cMichael.Wise%40microsoft.com%
> 7cd385a151ed9a43a298a108d3e22393f2%7c72f988bf86f141af91ab2d7cd011
> db47%7c1%7c0%7c636100614857988937&sdata=LqM2MVNcK6DP3g8gDG1K7gKfsGPdbQ
> Linx4zViyJ%2bRM%3d
> >
> >
> > --
> > Gilles Chehade
> >
> > https://na01.safelinks.protection.outlook.com/?url=
> https%3a%2f%2fwww.poolp.org&data=02%7c01%7cMichael.Wise%40microsoft.com%
> 7cd385a151ed9a43a298a108d3e22393f2%7c72f988bf86f141af91ab2d7cd011
> db47%7c1%7c0%7c636100614857988937&sdata=CgcRCVjKyFGk5aO21jd1ju25EhvMk6
> 5XZYOxcPZFVGY%3d  @poolpOrg
>
> --
> Gilles Chehade
>
> https://www.poolp.org  @poolpOrg
>
> ___
> 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] Breathe....

[Franck Martin via mailop]

I do not want to talk for the moderator/list owner but we have
representatives from all the different types of mail systems, small, big
and huge, that are engaged on this list.

Please be careful when you approach a problem you are facing, stick to the
facts, avoid adversarial language.

I think we want to keep everyone engaged. I know some issues are
frustrating...

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

Re: [mailop] Cloudflare not taking actions agains spamers?

[Franck Martin via mailop]

IMHO

It is hard to justify: take down this content because I received a bad
email.

You either ask the web content to be taken down because it is bad on its
own merit, or you ask the mail server admins to not send such bad emails.

To link the bad emails to a website needs a bit more work to prove a
definitive relationship.

On Tue, Sep 6, 2016 at 12:04 AM, Bill Cole <
mailop-20160...@billmail.scconsult.com> wrote:

> On 6 Sep 2016, at 1:04, Aaron C. de Bruyn wrote:
>
> Anyways, I thought there was a court case back in mid-90s where Compuserve
>> or Prodigy or something was ruled to not be responsible for content
>> flowing
>> through their networks as they are simply the conduit.
>>
>
> Cubby v. CompuServe and Stratton Oakmont v. Prodigy are probably what you
> half-recall.
> They were nuanced enough (or if you prefer: contradictory enough) that
> Congress felt compelled to pass a series of not-very-good laws like CDA,
> COPA, COPPA, CIPA, DMCA, and CAN-SPAM to clarify. Yeah, not so much...
>
> Anyway, I'm no lawyer and so can't give legal advice (but – funny story –
> I was very briefly sued for supposedly doing so) so take this for what it's
> worth. Note that those 2 cases were civil defamation suits because under US
> law it is really rather hard to publish anything in any medium that runs
> afoul of criminal law to a degree that the government will act. So when
> talking about legalities related to spam you're discussing mostly civil
> fraud or libel, both of which demand a specific victim with real damages.
>
> In short: US case law and US statutory law are both essentially
> irrelevant. It is not a question of whether CloudFlare is on sound legal
> ground under US law, it's a question of whether they are wrong in their
> actions. If you can't see the difference there, I can't help.
>
> Wouldn't that apply
>> to something like CloudFlare?
>>
>
> CloudFlare seems to be architected to assure that their services present
> jurisdictional challenges, so that's a layered question, but let's
> stipulate that CloudFlare is always entirely under US jurisdiction.
>
> The situation left by the two cited cases was a big fat headache. Prodigy
> was liable, CompuServe not, and there was a rather subtle (or perverse, if
> you prefer...) rationale for the difference. No higher court ever had a
> chance to unify that subtlety or establish a clear rational standard. As a
> result, later statutes almost all provided "safe harbor" provisions for
> ISPs that didn't quite make them common carriers (which they didn't
> actually want) but also gave them easy ways to avoid liability by acting in
> "good faith." Eventual case law has essentially made those provisions
> accessible to anyone providing any sort of service online. THOSE are the
> legal details that really protect a hypothetical CloudFlare that is fully
> under US jurisdiction.
>
> Note that this is also why mail system operators in the US can't be
> legally held to any sort of performance standard for mitigating the flow of
> spam through their systems as long as they don't overtly promote or protect
> blatantly illegal spam. I expect all the mailops who claim "you can't avoid
> sending out SOME spam" are glad for that protection.
>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Blocking emails from domains without SPF records

[Franck Martin via mailop]

I think we were talking here about rejecting emails from a domain that do
not have a SPF policy, which is a bit different from rejecting emails from
a domain with a SPF policy "-all" and a fail result.

For IPv6, bad stuff happens to non authenticated emails , as the archive on
this list is chowing. Look for stuff like "X is sending all my email to the
spam folder (because I just enabled IPv6 on my mail server)".

Also it is a M3AAWG recommendation that all emails on IPv6 must be
authenticated and the receivers to act accordingly (short crude summary).
https://www.m3aawg.org/sites/maawg/files/news/M3AAWG_Inbound_IPv6_Policy_Issues-2014-09.pdf

On Wed, Aug 17, 2016 at 3:06 PM, Michelle Sullivan 
wrote:

> Mark Foster wrote:
>
>>
>> By 'configured to do so', does Michelle mean , well, obeying SPF?
>>
>> Yes I mean if the receiving server is both checking SPF and enforcing the
> policy configured ;-) (sorry I did a really bad job of being clear :) )
>
>
> --
> Michelle Sullivan
> http://www.mhix.org/
>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Blocking emails from domains without SPF records

[Franck Martin via mailop]

I don't think you should block however:

-IPv4 rate limit if the email is not authenticated (pass SPF or DKIM)
-IPv6 reject email if it is not authenticated (pass SPF or DKIM)

On Wed, Aug 17, 2016 at 12:23 PM, Michelle Sullivan 
wrote:

> Brandon Long via mailop wrote:
>
>> If your mail server doesn't expect to get forwarded mail, I can see using
>> SPF like that.
>>
>> If you do expect to get forwarded mail, then it seems likely to cause
>> more false positives than it's worth.
>>
>>
> I don't see that...  Renaud just quoted https://www.iplocation.net/ema
> il-delivery-problems "Many mail servers refuse to accept emails from an
> IP address without SPF record" not that the SPF record should be
> restrictive when it comes to forwarded mail remembering the SPF is just
> to identify the places where a domains email may originate and whether the
> set policy is to be enforced or just used for information.  SPF doesn't
> stop forwarded email unless configured to do so... and not forgetting we're
> talking about where you're sending to, not about you receiving in this
> context.  Ie I may choose not to accept email from domains without SPF, if
> google.com doesn't have an SPF record it would just stop you sending to
> me, if you put in a +all or ?all record into google.com's DNS I would
> accept your email...
>
> Regards,
>
> --
> Michelle Sullivan
> http://www.mhix.org/
>
>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Facebook/Twitter, advice/anyone here?

[Franck Martin via mailop]

Thanks,

As with Apple, they used to remember your email address associated with
your credit card, now, likely due to privacy/security concerns, when you
want the receipt to be emailed to you, you need to type your email address
each time. Now, many people do not know their email address especially when
the system originally suggested for an already used email address was to
add a number to the email address. michelle@mailbox is taken but
michelle1@mailbox is free

Apple does not email credit card details in receipts. Well like in all
receipts, they only print the last 4 numbers of your credit card.

I'm not sure what is the solution here...

On Mon, Aug 15, 2016 at 2:29 PM, Michelle Sullivan 
wrote:

> Thoughts and suggestions people...
>
> I have about 2500 facebook and twitter accounts (current count) hitting my
> server on a daily basis  Neither Facebook nor Twitter seem to stop
> sending to them even with 550 User Unknown messages at SMTP time everytime
> they send... anyone know how to get these shut off, or would the only way
> be "hijack" all 2500 accounts and delete them?
>
> (linked in on the other hand are doing the right thing it seems - they
> stop sending after a couple of rejects..)
>
> Have a similar (though substantially smaller numbers) with Apple iCloud
> accounts... main problem there is people sending receipts for their
> purchases... you'd think they (the consumers) might be worried about a
> third-party getting all their (valid) credit card details, but I guess
> not
>
> Michelle
>
> --
> Michelle Sullivan
> http://www.mhix.org/
>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] domain research tools?

[Franck Martin via mailop]

https://www.farsightsecurity.com/DNSDB/

On Thu, Jul 28, 2016 at 2:10 AM, Autumn Tyr-Salvia 
wrote:

> Hello,
>
> I have recently been dealing with a spammer that likes to use lookalike
> domains and pretend to be other legitimate businesses before doing bad
> things. I want to do more research on the domains they're using.
>
> Do you do any domain research in the course of your work? If so, what
> tools do you use for research, and what do you like/dislike about them? I
> would ideally like an easy to use web interface that doesn't contain any
> ads or try to run too many third party scripts on my browser that is
> reliable and comprehensive, and preferably has some type of API access. I
> am largely interested in finding domains registered to the same contact,
> but looking into other data points as well. I'm happy to pay for a good
> service. My research needs are fairly low in volume at the moment, but I'm
> not sure if that would change if I had a tool I really liked.
>
> Reviews/links would be appreciated.
>
>
> Thanks,
>
> Autumn Tyr-Salvia
> autumn.tyrsalvia@sparkpost
> tyrsalvia@gmail
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Null MX & Preference

[Franck Martin via mailop]

indeed...

I think the null MX makes sense when there is an A or  on the same
domain. It stops the mail server to try to deliver and wait 4+ days to
bounce the message.

Other MX that are always fun to use:

MX 10 localhost

;)

On Thu, Jul 14, 2016 at 2:46 PM, Steve Atkins  wrote:

>
> > On Jul 14, 2016, at 2:39 PM, Franck Martin  wrote:
> >
> > I kind of see the null MX as a way to say that this domain does not send
> emails.
>
> Eh... only indirectly, implicitly and only kinda.
>
> 0-mx-dot states that the domain does not receive email for any address. It
> doesn't say anything directly about whether mail is sent using email
> addresses in that domain.
>
> If you believe that you must be able to deliver an asynchronous bounce for
> any message you receive, and you receive mail with an 821.From that you
> know is undeliverable then it's reasonable to treat that mail with a lot of
> suspicion.
>
> But 0-mx-dot is not an explicit statement by the domain owner of "mail is
> not sent using this domain". That'd be an SPF -all, or something DMARCy.
>
> Cheers,
>   Steve
>
> > So it is more a test on the receiving side than on the sending side.
> >
> > On Thu, Jul 14, 2016 at 2:04 PM, Steve Atkins  wrote:
> >
> > > On Jul 14, 2016, at 1:38 PM, Brian Godiksen 
> wrote:
> > >
> > > I noticed inconsistencies in how domains are publishing null MX
> records.  In RFC7505 it states these records should be published with a
> preference number 0.  I am seeing a variety of preferences specified though.
> > >
> > > Example:
> > >
> > > ;; QUESTION SECTION:
> > > ;hotmai.com.  IN  MX
> > >
> > > ;; ANSWER SECTION:
> > > hotmai.com.   2530IN  MX  10 .
> > >
> > > Is anyone ignoring the preference number in their implementation?
> >
> > More generally, is anyone special-casing this rather than just treating
> it as an idiomatic way of creating an email address that immediately fails
> to deliver?
> >
> > Cheers,
> >   Steve
> > ___
> > mailop mailing list
> > mailop@mailop.org
> > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
> >
>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Null MX & Preference

[Franck Martin via mailop]

I kind of see the null MX as a way to say that this domain does not send
emails. So it is more a test on the receiving side than on the sending side.

On Thu, Jul 14, 2016 at 2:04 PM, Steve Atkins  wrote:

>
> > On Jul 14, 2016, at 1:38 PM, Brian Godiksen 
> wrote:
> >
> > I noticed inconsistencies in how domains are publishing null MX
> records.  In RFC7505 it states these records should be published with a
> preference number 0.  I am seeing a variety of preferences specified though.
> >
> > Example:
> >
> > ;; QUESTION SECTION:
> > ;hotmai.com.  IN  MX
> >
> > ;; ANSWER SECTION:
> > hotmai.com.   2530IN  MX  10 .
> >
> > Is anyone ignoring the preference number in their implementation?
>
> More generally, is anyone special-casing this rather than just treating it
> as an idiomatic way of creating an email address that immediately fails to
> deliver?
>
> Cheers,
>   Steve
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Abuse Contacts hosted @ gmail and Google's Spam filter

[Franck Martin via mailop]

At best, is to put a rule to say not to deliver this email to the spam
folder, but if google wants to reject it, it will be rejected.

There is currently no way to deliver spam to abuse@

The best thing i have found, is to send an ARF with only the email headers
as per the standard, and add an extra mime part with an encrypted zip file
containing the full email, where I give the password in the mime text
portion.

On Tue, Jun 28, 2016 at 8:10 AM, Benoit Panizzon 
wrote:

> Hello
>
> Operating the experimental future SWINOG Spamtrap development and Spam
> Reporting infrastructure I often come across the problem, that many
> abuse desks have their abuse contact address hosted by Google.
>
> Unfortunately Google does not know about ARF Reports and very quickly
> considers an email spam, if it contains parts (headers) of an actual
> spam mail.
>
> I have been trying to contact ab...@google.com on several times about
> this exact issue, but never got any reaction.
>
> n...@google.com on the other hand is very responsible, but the employees
> there just tell me they have no clue who to contact about that issue
> within their company.
>
> So hopefully somebody from google is reading here or could point me in
> the right direction in trying to persuade google to switch their
> anti-spam rules to accept MIME-Type: message/feedback-report in
> combination with possibly the word 'abuse' in the email body and not
> block such emails as spam.
>
> Most recent sample:
>
> : host aspmx.l.google.com[2a00:1450:400c:c06::1a]
> said: 550-5.7.1 [2001:4060:1:1001::12:132  12] Our system has
> detected that this 550-5.7.1 message is likely unsolicited mail. To
> reduce the amount of spam sent 550-5.7.1 to Gmail, this message has
> been blocked. Please visit 550 5.7.1
> https://support.google.com/mail/answer/188131 for more information.
> s17si1188225wmd.135 - gsmtp (in reply to end of DATA command)
>
> From: abuse-arf-ro...@imp.ch
> To: ab...@cloudflare.com
> Subject: Abuse report about managesubscriber-187.com
> Date: Tue, 28 Jun 2016 17:01:32 +0200
> X-Mailer: MIME-tools 5.505 (Entity 5.505)
>
> [arf.txt  message/feedback-report (188 Bytes)]
>
> Dear ab...@cloudflare.com
>
> We found your address in the contact-database abusix.org. Should the
> data be incorrect, please read further down this message.
>
> [and so on...]
>
>
> -Benoît Panizzon-
> --
> I m p r o W a r e   A G-Leiter Commerce Kunden
> __
>
> Zurlindenstrasse 29 Tel  +41 61 826 93 00
> CH-4133 PrattelnFax  +41 61 826 93 01
> Schweiz Web  http://www.imp.ch
> __
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] why "not comply with best practices" on SpamRats?

[Franck Martin via mailop]

Junping,

I think many people don't know who netease is, at least your contribution
to this list will help.

I think the point people on this list are making is that you need to setup
specific PTR (that do not look like auto-generated) for the IPs that DO
send emails. You need to make sure all your dynamic IPs (and other IPs)
cannot send email directly and have to go through your mail servers.

Ideally the PTR should match what is in the helo (and vice versa).

Looking at your SPF, https://dmarcian.com/spf-survey/163.com, there are not
many IPs listed as potentially sending emails (compared to other SPF), so
you should be able to set some specific PTR for them.

Also as Suresh mentioned, if this blocking list is not blocking many emails
I would not worry much.


On Tue, Jun 14, 2016 at 6:11 AM, 陈俊平  wrote:

>
>
> Helpful thoughts Steve, many thanks again to you and to all :)
>
> Today Netease has 700+ million users and a lot of servers as well as IPs,
> you can see all IPs and ranges from the SPF record of domain 163.com,
> sothat we use the format "mxx-xx.domain" for reverse dns for balance.
>
> We keep reverse dns of our IPs to comply with standards and best
> practises, well, SpamRats doesn't elaborate the saying "best practise" on
> their page which'd create confusion.
>
> If I have no luck to receive SpamRats' reply then I will try changing the
> reverse dns of 123.58.177.172, for example:
>
> dig +short -x 123.58.177.172
> m172-177.vip.163.com. <== present
> mail-wmsvr2.vip.163.com. <== new
>
>
> Regards,
>
> -Junping
>
>
>
> 在 2016-06-14 20:47:41，"Steve Freegard"  写道：
>
>
>
> On 14/06/16 13:16, "陈俊平 via mailop.org" 
>  wrote:
>
>
> Here're some reverse dns of big senders, they also use the format
> "x-x.xx.domain".
>
> *$ dig +short -x 98.136.219.65*
> *ng5-vm13.bullet.mail.gq1.yahoo.com
> .*
>
>
> Doesn't contain any octets of the IP address
>
>
> *$ dig +short -x 209.85.218.44*
> *mail-oi0-f44.google.com .*
>
>
> Has a single octet of the IP address but clearly shows mail- as the
> function.  My own heuristics would allow this, can't speak for others.
>
> *$ dig +short -x 17.171.37.67*
> *mdn-txn-msbadger0502.apple.com .*
>
>
> Again - no octets of the IP address appear within the name.
>
> Kind regards,
> Steve.
>
> --
> Steve Freegard
> Development Director
> Fort Systems Ltd.
>
>
>
>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Messages over IPv6 rejected by Google for failed authentication checks

[Franck Martin via mailop]

On Thu, Jun 9, 2016 at 2:59 PM, Laura Atkins 
wrote:

>
> > On Jun 9, 2016, at 2:07 PM, Bernhard Schmidt 
> wrote:
> >
> > On 09.06.2016 18:20, Laura Atkins wrote:
> >>
> >>> On Jun 9, 2016, at 9:06 AM, Bernhard Schmidt 
> wrote:
> >>>
> >>> Header-From and Envelope-From are aligned, the sending domain does not
> >>> have any DKIM/SPF/DMARC published. We're working on DKIM, but this is
> >>> not rolled out for all domains yet. The hosts in question do have
> proper
> >>> FCrDNS, i.e.
> >>>
> >>>
> http://multirbl.valli.org/fcrdns-test/2001%3A4ca0%3A0%3A103%3A%3A81bb%3Aff89.html
> >>>
> >>> Anyone seeing the same? From outside it looks like Google has
> >>> implemented the "all mail delivered over IPv6 has to be DKIM/SPF
> >>> authenticated" previously done by Microsoft, but without the softfail.
> >>
> >> Yes. They have. They do not accept unauthenticated mail over v6. All
> you need to do is publish a SPF record and you should be good to go.
> >
> > Adding an SPF record for some remote understaffed downstream university
> > institute is not that easy if you don't know where their mail flows
> > might come from. Forcing SPF on them might do more harm than good.
>
> I didn’t notice it was a university. That I know how problematic it is to
> get control of a .edu domain and all the different campus servers and
> individual servers run by faculty and staff and such. Had I know I probably
> wouldn’t have recommended that.
>
>
Yes it is hard to know the IPs of where all the emails are coming from but
you can start by an SPF record with the IPs you know about and terminate it
by ~all. the ~all just says, if it does not pass it may be still ok.

You complete the SPF as you learn more about your infrastructure and what
is not working.

I don't think you need the gift of omniscience to get started with SPF.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Messages over IPv6 rejected by Google for failed authentication checks

[Franck Martin via mailop]

On Thu, Jun 9, 2016 at 11:48 AM, Michael Peddemors 
wrote:

> On 16-06-09 11:26 AM, Franck Martin via mailop wrote:
>
>> As people pointed out, an SPF record is easy to set and fast to solve
>> the issue, DKIM can come later...
>>
>
> Hehehe... 'easy' is a relative word, amazing how many poor SPF records are
> out there, and sometimes it is hard enough to get email operators to even
> have proper PTR records..
>
> There has been little pain so far, stupid things have happened and there
were barely any difference...
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Messages over IPv6 rejected by Google for failed authentication checks

[Franck Martin via mailop]

It is a M3AAWG best practice to not accept unauthenticated emails over
IPv6, Microsoft does it, we do it, Google too...
https://www.m3aawg.org/sites/default/files/document/M3AAWG_Inbound_IPv6_Policy_Issues-2014-09.pdf

It is also likely that bad stuff (less visible for the sender) is also
happening to unauthenticated emails over IPv4. There is only 3% of "good"
emails that are unauthenticated (true it is from the long tail of sending
domains but...):
https://security.googleblog.com/2013/12/internet-wide-efforts-to-fight-email.html

As people pointed out, an SPF record is easy to set and fast to solve the
issue, DKIM can come later...

On Thu, Jun 9, 2016 at 9:38 AM, Bernhard Schmidt 
wrote:

> On 09.06.2016 18:18, Hugo Slabbert wrote:
>
> Hi,
>
> >> since around 13:00 UTC today all of the sudden we see massive rejects of
> >> mails towards Google when delivering on IPv6
> >>
> >> Jun  9 15:12:07 lxmhs52 postfix-postout/smtp[50664]: 3rQQgp3VQTzyWn:
> >> to=,
> >> relay=gmail-smtp-in.l.google.com[2a00:1450:400c:c0a::1b]:25, delay=0.7,
> >> delays=0.01/0/0.16
> >> /0.53, dsn=5.7.1, status=bounced (host
> >> gmail-smtp-in.l.google.com[2a00:1450:400c:c0a::1b] said: 550-5.7.1 This
> >> message does not have authentication information or fails to pass
> >> 550-5.7.1 authentication checks. To best protect our users from spam,
> >> the 550-5.7.1 message has been blocked. Please visit 550-5.7.1
> >> https://support.google.com/mail/answer/81126#authentication for m
> >> ore 550 5.7.1 information. d7si7802319wjc.145 - gsmtp (in reply to end
> >> of DATA command))
> >>
> >> Header-From and Envelope-From are aligned, the sending domain does not
> >> have any DKIM/SPF/DMARC published. We're working on DKIM, but this is
> >> not rolled out for all domains yet. The hosts in question do have proper
> >> FCrDNS, i.e.
> >>
> >>
> http://multirbl.valli.org/fcrdns-test/2001%3A4ca0%3A0%3A103%3A%3A81bb%3Aff89.html
> >>
> >>
> >> Anyone seeing the same? From outside it looks like Google has
> >> implemented the "all mail delivered over IPv6 has to be DKIM/SPF
> >> authenticated" previously done by Microsoft, but without the softfail.
> >
> > ...hasn't this been the case for some time?  They want FCrDNS + at least
> > one of SPF or DKIM to accept delivery over v6:
> >
> > https://support.google.com/mail/answer/81126?hl=en#authentication
> >
> > Did they just defer previously?
>
> Mail was accepted just fine until three hours ago. There is a large
> difference between "The sending domain should pass either SPF check or
> DKIM check. Otherwise, mail might be marked as spam." and outright
> rejecting 100% of it.
>
> We've been working on SPF/DKIM for quite some time now. Unfortunately
> this is not that easy with hundreds of faculty-operated servers/domains,
> some of them not even on our nameservers. This has de-facto killed IPv6
> outbound completely for us. Microsoft tempfailing was annoying enough
> but manageable.
>
> Best Regards,
> Bernhard
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] DKIM CNAME temperror from Microsoft - 1024 bit vs. 2048 bit

[Franck Martin via mailop]

May be they should test their DNS servers using:
https://www.dns-oarc.net/oarc/services/replysizetest

or setup edns udp size to 1400 instead of the default 4096 is they don't
want to allow fragmented packets in:
http://www.zytrax.com/books/dns/ch7/hkpng.html#edns-udp-size

This is also likely to affect SPF results when the zone is overloaded with
TXT record at the root, and even more when you enable DNSSEC verification...

On Tue, Jun 7, 2016 at 10:41 AM, Steve Atkins  wrote:

>
> > On Jun 7, 2016, at 10:31 AM, Simon  wrote:
> >
> > Am 07.06.2016 um 18:27 schrieb Steve Atkins:
> >> The 2048 bit key plus the CNAME gives a reply packet big enough that
> >> the UDP reply to a non-edns query is truncated. Retrying over TCP
> >> works, but a DNS resolver that doesn't do TCP would just error out.
> >> That's probably why the DKIM temperror. If you make your reply small
> >> enough that a UDP reply works (either by not using the CNAME in the
> >> same zone, or by using a slightly smaller key) I expect it'd go away.
> >
> > Yes at some point it will start to work when sending to hotmail.com,
> > outlook.com. Interestingly Google, Yahoo, AOL & Co don't seem to mind
> > switching protocols during key retrieval.
> >
> > That explains why those ESPs that want you to set a CNAME from your zone
> > pointing to a pubkey in their zone don't use 2048 bit keys yet.
>
> A CNAME in a different zone would likely not have the issue. But 1536 bit
> keys
> might be the sweet spot anyway, I guess. DNS is a little fragile when you
> push
> it's historical limits.
>
> Cheers,
>   Steve
>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Gmail throttling our office mail server

[Franck Martin via mailop]

The trouble is his spam becomes your spam and you get penalized for that...

Get on the google postmaster tools to have a better idea of what is
happening, but I would not blindly trust someone that relay emails through
my servers...

On Fri, Jun 3, 2016 at 4:30 AM,  wrote:

> Hi,
>
> I'm currently seeing only this error
>
> 421-4.7.0 Our system has detected an unusual rate of unsolicited mail
> originating from your IP address. To protect our users from spam, mail
> sent from your IP address has been temporarily rate limited. Please
> visit https://support.google.com/mail/answer/81126 to review our Bulk E
> mail Senders Guidelines. vx5si6861009wjc.33 - gsmtp
>
> for all Mails going from 213.61.69.122 (office.optivo.de) to any Google
> Apps Domain or Gmail Recipient. It's not much traffic (2k mails in a
> week). I'm pretty sure I identified the reason for that, we had an
> relay setting for an external user who is hosting his mail on Google
> apps and besides simple spam filtering we relayed everything.
>
> I really hope that this is the only reason, because on this host 99% of
> the traffic is one2one communication and therefore should not trigger
> any bulk filter...
>
> Would be nice if somebody who is able to look into this, could give me
> a short catchup if we have any other issues on this host...
>
> Kind regards,
>
> / Tobias Herkula
>
> --
> optivo GmbH
> Head of Deliverability & Abuse Management
> Wallstraße 16
> 10179 Berlin
> Germany
>
> Tel: +49(0)30-768078-129
> Fax: +49(0)30-768078-499
>
> Email:mailto:t.herk...@optivo.com
> Website:  http://www.optivo.com
> Linkedin: http://www.linkedin.com/in/tobiasherkula
>
> Commercial register: HRB 88738 District Court Berlin-Charlottenburg
> Executive board: Dr. Rainer Brosch, Thomas Diezmann
> Vat reg. no.: DE813696618
>
> optivo A company of Deutsche Post DHL Group
>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] signup form abuse

[Franck Martin via mailop]

Not new story, people have devised systems to avoid the creation of such
accounts:
http://bits.blogs.nytimes.com/2013/04/05/fake-twitter-followers-becomes-multimillion-dollar-business/?_r=0

You could for instance use data from http://www.e-hawk.net/ (I'm not
endorsing them, just a company that tries to fill that need, there are
others, do due diligence) to trust (or not) that the signing up is from a
legit person and if not increase the challenge level (CAPCHA and others).

On Tue, May 24, 2016 at 11:18 AM, Michael Wise via mailop  wrote:

> Are these IP addresses on CBL?
>
> Are these addresses in a larger pool, like a Nigerian coffee shop?
>
> At some point, you should have a CAPTCHA, and also possibly a list of
> ranges of known bad actors.
>
>
>
> We’ve been so concerned about issues from bad IPs on port 25, that many of
> us have neglected noticing bad connections on port 443.
>
>
>
> Aloha,
>
> Michael.
>
> --
>
> *Michael J Wise* | Microsoft | Spam Analysis | "Your Spam Specimen Has
> Been Processed." | Got the Junk Mail Reporting Tool
>  ?
>
>
>
> *From:* mailop [mailto:mailop-boun...@mailop.org] *On Behalf Of *Vick
> Khera
> *Sent:* Tuesday, May 24, 2016 10:18 AM
> *To:* mailop@mailop.org
> *Subject:* [mailop] signup form abuse
>
>
>
> As an ESP, we host mailing list signup forms for many customers. Of late,
> it appears they have been getting pounded on with fraudulent signups for
> real addresses. Sometimes the people confirm by clicking the confirmation
> link in the message and we are left scratching our heads as to why they
> would do that. Mostly they get ignored and sometimes they come back as spam
> complaints.
>
>
>
> One opinion I got regarding this was that people were using bots to sign
> up to newsletter lists other bot-driven email addresses at gmail, yahoo,
> etc., to make those mailboxes look more real before they became
> "weaponized" for use in sending junk. That does not seem to be entirely
> what is happening here...
>
>
>
> Today we got a set of complaints for what appears to be a personal email
> address at a reasonably sized ISP. The complaint clearly identified the
> messages as a signup confirmation message and chastised us for not having
> the form protected by a CAPTCHA. Of course, they blocked some of our IPs
> for good measure :( They characterized it as a DDoS.
>
>
>
> What are the folks on this fine list doing about this kind of abuse? We do
> have ability to turn on CAPTCHA for our customers, but often they have
> nicely integrated the signup forms into their own web sites and making it
> work for those is pretty complicated. If I enabled CAPTCHA naively, the
> subscribers would have to click the submit form twice and then click the
> confirm on the email. The UX for that sucks, but such is the cost of
> allowing jerks on the internet...
>
>
>
> Rate limiting doesn't seem to be useful since the forms are being
> submitted at low rates and from a wide number of IP addresses.
>
>
>
> I look forward to hearing what others here are doing.
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Outgoing TLS

[Franck Martin via mailop]

These posts will give you more hindsight:
https://www.facebook.com/notes/protect-the-graph/massive-growth-in-smtp-starttls-deployment/1491049534468526/
https://www.facebook.com/notes/protect-the-graph/the-current-state-of-smtp-starttls-deployment/1453015901605223

On Thu, May 12, 2016 at 10:47 AM,  wrote:

> On Thu, May 12, 2016, Jeffry Dwight wrote:
>
> > So, what do you all do? Right now, I'm verifying the cert and its chain,
> but
> > ignoring CN mismatches. That seems to be fine for ensuring encryption,
> but
>
> Only log "problems" (why should I trust some CA?) unless explicitly
> configured to check (for a few "important"/"known" hosts).
>
> > rather defeats the purpose of knowing we're connecting to the proper
> server.
>
> DANE.
>
> > Second question: How do you handle self-signed certs? Do you just ignore
> cases
> > where the root isn't a trusted root?
>
> Same as above.
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Cisco PIX Mailguard Oddity

[Franck Martin via mailop]

If your network people think they can do a better job than your mail
people, then give them the management of your mail servers, otherwise, tell
them to disable cisco fixup (or whatever it is called nowadays).

On Fri, May 6, 2016 at 8:15 AM, Steve Atkins  wrote:

>
> > On May 6, 2016, at 6:04 AM, Todd Herr  wrote:
> >
> >
> > On Thu, May 5, 2016 at 9:00 PM, Steve Atkins  wrote:
> > I've seen them do that when they get out of sequence. Are you doing the
> transaction above by hand (and with a real HELO and so on), or is it from
> MTA logs?
> >
> > ​By hand, real HELO and MAIL FROM, followed by RSET or QUIT, but AIUI,
> RSET or QUIT can be issued at any time, yes?
>
> Yes they can, but I've seen PIXes inexplicably get into a state where they
> reject everything.
>
> Also, they can't handle (with at least some firmware revisions) SMTP
> commands broken across TCP packet boundaries. If you're interacting with
> them using a character-at-a-time tool rather than a line-at-a-time tool
> then that would cause all commands not to be recognized, unless you type
> fast enough to beat Nagle.
>
> Telnet (at least on unixy platforms) defaults to line-at-a-time, I think.
>
> Cheers,
>   Steve
>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] DNS Errors for Microsoft Hostnames

[Franck Martin via mailop]

On Fri, May 6, 2016 at 3:22 AM, Tony Finch  wrote:

> Franck Martin via mailop  wrote:
>
> > This page, provides a way to test EDNS:
> > https://www.dns-oarc.net/oarc/services/replysizetest
>
> That's testing the EDNS large packet feature. A DNS server can support
> EDNS without supporting large packets.
>
> which is not the default with bind...
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] DNS Errors for Microsoft Hostnames

[Franck Martin via mailop]

This page, provides a way to test EDNS:
https://www.dns-oarc.net/oarc/services/replysizetest

Bind acts this way.

Makes an EDNS query of full size, if no answer, makes a DNS query and
request the response to be limited to a 512bytes answer, there it usually
will get an answer, that the result is too big to fit in such UDP packet
therefore, bind finally makes the query over TCP and gets the result needed.

With low TTL, overloaded TXT records, it is not rare that the mail server
does not get the SPF record in time for a non null but significant portion
of emails from a domain.

UDP fragments are not a security issue, they are essential for DNS.

On Thu, May 5, 2016 at 3:29 AM, Tony Finch  wrote:

> Michael Wise  wrote:
> >
> > So is the FORMERR ... just the resolver noting that EDNS is not
> supported?
> >
> > If so, I'm uncertain of the issue.
>
> There has been some discussion of this problem on the bind-users list, see
> https://lists.isc.org/pipermail/bind-users/2016-May/thread.html
>
> The problems seem to be:
>
> (1) Very short TTL on the NS records, which means that most attempts to
> resolve the names have to go through iterative name server discovery.
>
> (2) Only two NS records, but each server has a large number of IP
> addresses, and the sets of IP addresses overlap.
>
> (3) Lack of EDNS support means more work has to be done by a resolver each
> time the TTL expires.
>
> The way to fix this would be to increase the stability of the name server
> records - the NS records and associated address records. Give them
> decently long TTLs, have a few more NS records, with few non-overlapping
> IP addresses each.
>
> Add support for EDNS to your server - you don't need to support any
> special EDNS features (no need for large packets), just handle OPT
> records, so that resolvers don't have to do error recovery.
>
> Tony.
> --
> f.anthony.n.finchhttp://dotat.at/  -  I xn--zr8h
> punycode
> Irish Sea: South 4 or 5 becoming variable 3 or 4. Slight or moderate.
> Occasional drizzle, fog patches in north. Moderate or good, occasionally
> very
> poor in north.
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] DNS Errors for Microsoft Hostnames

[Franck Martin via mailop]

I use this tool because it checks everything DNS (including DNSSEC) and
makes a pretty graph. The two errors are not related to DNSSEC, so seems
you have something to fix ;)

On Wed, May 4, 2016 at 5:03 PM, Michael Wise 
wrote:

>
>
> Microsoft officially doesn’t do DNSSEC.
> (or at least not now anyway)
>
>
>
> Aloha,
>
> Michael.
>
> --
>
> *Michael J Wise* | Microsoft | Spam Analysis | "Your Spam Specimen Has
> Been Processed." | Got the Junk Mail Reporting Tool
>  ?
>
>
>
> *From:* Franck Martin [mailto:fmar...@linkedin.com]
> *Sent:* Wednesday, May 4, 2016 4:20 PM
> *To:* Rob Heilman 
> *Cc:* Michael Wise ; mailop@mailop.org
>
> *Subject:* Re: [mailop] DNS Errors for Microsoft Hostnames
>
>
>
> I like to use this tool to tell me everything...
>
>
>
> I used it on the first domain, told me there are 2 errors:
>
> http://dnsviz.net/d/alleghenycourts-us.mail.protection.outlook.com/dnssec/
>
>
>
> On Wed, May 4, 2016 at 8:45 AM, Rob Heilman  wrote:
>
> Got a fresh batch of DNS failures in the logs.  Below is a sampling.  From
> the BIND source code resolver.c:
>
>
>
> } else if (result != ISC_R_SUCCESS) {
> /*
>  * Something bad happened.
>  */
> fctx_done(fctx, result, __LINE__);
> return;
> }
>
>
>
> Has anyone seen this before or know what might be happening?  If not I
> will try to escalate to ISC to see if they can help diagnose.
>
>
>
> -Rob Heilman
>
>
>
> 04-May-2016 09:46:22.236 query-errors: debug 1: client 10.10.10.95#44080 (
> alleghenycourts-us.mail.protection.outlook.com): query failed (SERVFAIL)
> for alleghenycourts-us.mail.protection.outlook.com/IN/A at query.c:7004
> 04-May-2016 09:46:22.236 query-errors: debug 1: client 10.10.10.95#44080 (
> courts-phila-gov.mail.protection.outlook.com): query failed (SERVFAIL)
> for courts-phila-gov.mail.protection.outlook.com/IN/A at query.c:7004
> 04-May-2016 09:46:22.236 query-errors: debug 2: fetch completed at
> resolver.c:3074 for alleghenycourts-us.mail.protection.outlook.com/A
> in 0.000122: failure/success [domain:mail.protection.outlook.com
> ,referral:0,restart:1,qrysent:0,timeout:0,lame:0,neterr:0,badresp:0,adberr:2,findfail:0,valfail:0]
> 04-May-2016 09:46:22.236 query-errors: debug 2: fetch completed at
> resolver.c:3074 for courts-phila-gov.mail.protection.outlook.com/A
> in 0.000272: failure/success [domain:mail.protection.outlook.com
> ,referral:0,restart:1,qrysent:0,timeout:0,lame:0,neterr:0,badresp:0,adberr:2,findfail:0,valfail:0]
> 04-May-2016 09:46:49.389 query-errors: debug 1: client 10.10.10.96#48950 (
> petersoncpa-com02b.mail.protection.outlook.com): query failed (SERVFAIL)
> for petersoncpa-com02b.mail.protection.outlook.com/IN/A at query.c:7004
> 04-May-2016 09:46:49.389 query-errors: debug 2: fetch completed at
> resolver.c:3074 for petersoncpa-com02b.mail.protection.outlook.com/A
> in 0.78: failure/success [domain:mail.protection.outlook.com
> ,referral:0,restart:1,qrysent:0,timeout:0,lame:0,neterr:0,badresp:0,adberr:2,findfail:0,valfail:0]
> 04-May-2016 09:47:22.030 query-errors: debug 1: client 10.10.10.96#48950 (
> supervaluinc.mail.protection.outlook.com): query failed (SERVFAIL) for
> supervaluinc.mail.protection.outlook.com/IN/A at query.c:7004
> 04-May-2016 09:47:22.030 query-errors: debug 2: fetch completed at
> resolver.c:3074 for supervaluinc.mail.protection.outlook.com/A in
> 0.84: failure/success [domain:mail.protection.outlook.com
> ,referral:0,restart:1,qrysent:0,timeout:0,lame:0,neterr:0,badresp:0,adberr:2,findfail:0,valfail:0]
> 04-May-2016 09:47:25.817 query-errors: debug 1: client 10.10.10.96#48950 (
> casella-com.mail.protection.outlook.com): query failed (SERVFAIL) for
> casella-com.mail.protection.outlook.com/IN/A at query.c:7004
> 04-May-2016 09:47:25.817 query-errors: debug 2: fetch completed at
> resolver.c:3074 for casella-com.mail.protection.outlook.com/A in
> 0.92: failure/success [domain:mail.protection.outlook.com
> ,referral:0,restart:1,qrysent:0,timeout:0,lame:0,neterr:0,badresp:0,adberr:2,findfail:0,valfail:0]
> 04-May-2016 09:47:26.792 query-errors: debug 1: client 10.10.10.95#44080 (
> ghscoslaw-com.mail.protection.outlook.com): query failed (SERVFAIL) for
> ghscoslaw-com.mail.protection.outlook.com/IN/A at query.c:7004
> 04-May-2016 09:47:26.792 query-errors: debug 2: fetch completed at
> resolver.c:3074 for ghscoslaw-com.mail.protection.outlook.com/A in
> 0.93: failure/success [domain:mail.protection.outlook.com
> ,referral:0,restart:1,qrysent:0,timeout:0,lame:0,neterr:0,badresp:0,adberr:2,findfail:0,valfail:0]
> 04-May-2016 09:47:27.855 query-errors: debug 1: client 10.10.10.95#44080 (
> casella-com.mail.protection.outlook.com): query failed (SERVFAIL) for
> casella-com.mail.protection.outlook.com/IN/A at query.c:7004
> 04-May-2016 09:47:27.855 query-errors: de

Re: [mailop] DNS Errors for Microsoft Hostnames

[Franck Martin via mailop]

I like to use this tool to tell me everything...

I used it on the first domain, told me there are 2 errors:
http://dnsviz.net/d/alleghenycourts-us.mail.protection.outlook.com/dnssec/

On Wed, May 4, 2016 at 8:45 AM, Rob Heilman  wrote:

> Got a fresh batch of DNS failures in the logs.  Below is a sampling.  From
> the BIND source code resolver.c:
>
> } else if (result != ISC_R_SUCCESS) {
> /*
>  * Something bad happened.
>  */
> fctx_done(fctx, result, __LINE__);
> return;
> }
>
> Has anyone seen this before or know what might be happening?  If not I
> will try to escalate to ISC to see if they can help diagnose.
>
> -Rob Heilman
>
> 04-May-2016 09:46:22.236 query-errors: debug 1: client 10.10.10.95#44080 (
> alleghenycourts-us.mail.protection.outlook.com): query failed (SERVFAIL)
> for alleghenycourts-us.mail.protection.outlook.com/IN/A at query.c:7004
> 04-May-2016 09:46:22.236 query-errors: debug 1: client 10.10.10.95#44080 (
> courts-phila-gov.mail.protection.outlook.com): query failed (SERVFAIL)
> for courts-phila-gov.mail.protection.outlook.com/IN/A at query.c:7004
> 04-May-2016 09:46:22.236 query-errors: debug 2: fetch completed at
> resolver.c:3074 for alleghenycourts-us.mail.protection.outlook.com/A
> in 0.000122: failure/success [domain:mail.protection.outlook.com
> ,referral:0,restart:1,qrysent:0,timeout:0,lame:0,neterr:0,badresp:0,adberr:2,findfail:0,valfail:0]
> 04-May-2016 09:46:22.236 query-errors: debug 2: fetch completed at
> resolver.c:3074 for courts-phila-gov.mail.protection.outlook.com/A
> in 0.000272: failure/success [domain:mail.protection.outlook.com
> ,referral:0,restart:1,qrysent:0,timeout:0,lame:0,neterr:0,badresp:0,adberr:2,findfail:0,valfail:0]
> 04-May-2016 09:46:49.389 query-errors: debug 1: client 10.10.10.96#48950 (
> petersoncpa-com02b.mail.protection.outlook.com): query failed (SERVFAIL)
> for petersoncpa-com02b.mail.protection.outlook.com/IN/A at query.c:7004
> 04-May-2016 09:46:49.389 query-errors: debug 2: fetch completed at
> resolver.c:3074 for petersoncpa-com02b.mail.protection.outlook.com/A
> in 0.78: failure/success [domain:mail.protection.outlook.com
> ,referral:0,restart:1,qrysent:0,timeout:0,lame:0,neterr:0,badresp:0,adberr:2,findfail:0,valfail:0]
> 04-May-2016 09:47:22.030 query-errors: debug 1: client 10.10.10.96#48950 (
> supervaluinc.mail.protection.outlook.com): query failed (SERVFAIL) for
> supervaluinc.mail.protection.outlook.com/IN/A at query.c:7004
> 04-May-2016 09:47:22.030 query-errors: debug 2: fetch completed at
> resolver.c:3074 for supervaluinc.mail.protection.outlook.com/A in
> 0.84: failure/success [domain:mail.protection.outlook.com
> ,referral:0,restart:1,qrysent:0,timeout:0,lame:0,neterr:0,badresp:0,adberr:2,findfail:0,valfail:0]
> 04-May-2016 09:47:25.817 query-errors: debug 1: client 10.10.10.96#48950 (
> casella-com.mail.protection.outlook.com): query failed (SERVFAIL) for
> casella-com.mail.protection.outlook.com/IN/A at query.c:7004
> 04-May-2016 09:47:25.817 query-errors: debug 2: fetch completed at
> resolver.c:3074 for casella-com.mail.protection.outlook.com/A in
> 0.92: failure/success [domain:mail.protection.outlook.com
> ,referral:0,restart:1,qrysent:0,timeout:0,lame:0,neterr:0,badresp:0,adberr:2,findfail:0,valfail:0]
> 04-May-2016 09:47:26.792 query-errors: debug 1: client 10.10.10.95#44080 (
> ghscoslaw-com.mail.protection.outlook.com): query failed (SERVFAIL) for
> ghscoslaw-com.mail.protection.outlook.com/IN/A at query.c:7004
> 04-May-2016 09:47:26.792 query-errors: debug 2: fetch completed at
> resolver.c:3074 for ghscoslaw-com.mail.protection.outlook.com/A in
> 0.93: failure/success [domain:mail.protection.outlook.com
> ,referral:0,restart:1,qrysent:0,timeout:0,lame:0,neterr:0,badresp:0,adberr:2,findfail:0,valfail:0]
> 04-May-2016 09:47:27.855 query-errors: debug 1: client 10.10.10.95#44080 (
> casella-com.mail.protection.outlook.com): query failed (SERVFAIL) for
> casella-com.mail.protection.outlook.com/IN/A at query.c:7004
> 04-May-2016 09:47:27.855 query-errors: debug 2: fetch completed at
> resolver.c:3074 for casella-com.mail.protection.outlook.com/A in
> 0.90: failure/success [domain:mail.protection.outlook.com
> ,referral:0,restart:1,qrysent:0,timeout:0,lame:0,neterr:0,badresp:0,adberr:2,findfail:0,valfail:0]
> 04-May-2016 09:47:55.476 query-errors: debug 1: client 10.10.10.95#44080 (
> slcccpa-com.mail.protection.outlook.com): query failed (SERVFAIL) for
> slcccpa-com.mail.protection.outlook.com/IN/A at query.c:7004
> 04-May-2016 09:47:55.477 query-errors: debug 2: fetch completed at
> resolver.c:3074 for slcccpa-com.mail.protection.outlook.com/A in
> 0.79: failure/success [domain:mail.protection.outlook.com
> ,referral:0,restart:1,qrysent:0,timeout:0,lame:0,neterr:0,badresp:0,adberr:2,findfail:0,valfail:0]
> 04-May-2016 09:47:58.769 query-err

Re: [mailop] SPF check overly stringent?

[Franck Martin via mailop]

I like to use https://dmarcian.com/spf-survey/sigiowa.com for checking SPF
(and DMARC)

On Fri, Apr 29, 2016 at 9:52 AM, Frank Bulk  wrote:

> We're helping a customer (sigiowa.com) who's having issues sending emails
> to
> the USDA.  Our email server logs this:
> Site usda.gov (2a01:111:f400:7c10::10) said after data sent: 450
> 4.7.26 Service does not accept messages sent over IPv6
> [2607:fe28:0:4000::20] unless they pass either SPF or DKIM validation
> (message not signed)
>
> Just this morning I changed their SPF record from this:
> "v=spf1 mx ip4:96.31.0.0/24 ip6:2607:fe28:0:1000::/64
> ip6:2607:fe28:0:4000::/64 ~all"
> to this:
> "v=spf1 ip4:96.31.0.0/24 ip6:2607:fe28:0:4000::20
> ip6:2607:fe28:0:1000::/64 ip6:2607:fe28:0:4000::/64 ~all"
>
> I added in ip6:2607:fe28:0:4000::20 because I'm wondering if the USDA's
> system doesn't properly identify the sending IP of 2607:fe28:0:4000::20 as
> part of 2607:fe28:0:4000::/64.  I also removed 'mx' because this tool
> (http://vamsoft.com/support/tools/spf-policy-tester) was failing on
> pulling
> the  for each of the domain's four MX records.  Try the vamsoft site
> with 2607:fe28:0:4000::20 and fb...@premieronline.net to see how
> sigiowa.com
> used to fail.
>
> Is Vamsoft's check too stringent?  Does it seriously matter that it can't
> find the  for the domain's four MX records?  Shouldn't an SPF check for
> the domain's MX records just look for an A or ?
>
> Regards,
>
> Frank
>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] DNS Errors for Microsoft Hostnames

[Franck Martin via mailop]

For EDNS to work correctly you MUST accept UDP fragmented packets, or
configure your DNS server to advertise a max EDNS packet size of about 1200
bytes.

Otherwise, bind, for instance, goes in a series of fallback and by the time
the result is available the mail server has moved on...

On Thu, Apr 28, 2016 at 2:16 PM, Carl Byington  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On Thu, 2016-04-28 at 20:57 +, Michael Wise wrote:
> > If the "Aware" flag expired, would best practice not be to check that
> > first rather than presuppose that the facility does exist?
>
> The check for "edns aware" involves sending the query with edns
> extensions. If the reply is formerr (or possibly others?), then you can
> remember that this server does not understand edns, and repeat the query
> without it.
>
> If you just do the first query without edns, there is no mechanism to
> then learn that that server does indeed understand edns.
>
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.14 (GNU/Linux)
>
> iEYEAREKAAYFAlcifY8ACgkQL6j7milTFsEyTgCfbLe36v3LuECg+Ma4/mjxq52c
> C9oAnjFeZYZjl2//eCsWM3NvkeWwthUy
> =H2pv
> -END PGP SIGNATURE-
>
>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Still seeing throttling/delays from google apps after 3 weeks.

[Franck Martin via mailop]

You should have done DKIM on your old IP before moving, so you could have
carried over your domain reputation to the new IP.

On Wed, Apr 27, 2016 at 4:04 PM, Robert Guthrie  wrote:

> Hi List,
>
> Just wanted to check in and see if there is anything else I can do to get
> emails to arrive immediately rather than be delayed a few hours - this only
> concerns delivery to google apps accounts.
>
> Our outbound smtp (smtp.loomio.org) is using TLS, SPF, DKIM and a
> reasonable percentage of the 45K/day we send get opened. It's relatively
> new, about a month old and it was started on a fresh IP - I should have
> reused the old IP (alas the old IP has been relinquished)
>
> Previously we were sending the same volume of email, but without TLS or
> DKIM, but the IP was warmed up organically and we never had delays with
> google apps.
>
> The throttling varies day to day, some times emails arrive instantly, but
> other days there is a big delay. Is there anything I can do to help bring
> the throttling down and keep it down?
>
> Sigh. Thanks for your help!
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] "Spammer TLDs" and IP addresses without a reverse?

[Franck Martin via mailop]

On Tue, Apr 19, 2016 at 12:05 PM, Michael Peddemors 
wrote:

> On 16-04-19 11:53 AM, Michael Wise wrote:
>
>> ... unless it's coming from your localnet.
>> Local clients in the IP space "You Own" should get a bit more slack.
>> IMHO.
>>
>> Aloha,
>> Michael.
>>
>>
> Yeah, only for MTA->MTA traffic, not MTU->MTA, if that is what you mean..
>
>
Indeed, nowadays you should not accept MUA connections to port 25, there is
submission port 587 for that.
___
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

[Franck Martin via mailop]

https://dmarcian.com/dmarc-inspector/chinalovecupid.com

says all is fine

Also note you need some traffic, before an aggregate report is sent to you.
Some receivers will not send a daily report if they have not seen X emails
from your domain.

at https://dmarc.org/resources/deployment-tools/

you will find in message validation, a few email address that will send you
reports very quickly, like autore...@dmarctest.org

On Thu, Apr 14, 2016 at 3:51 PM, Renaud Allard via mailop  wrote:

>
>
> 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
>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Speaking of Banks, Pet Peeve SPF

[Franck Martin via mailop]

I prefer

example.com TXT "v=spf1 ip:0.0.0.0/0 -all"

or more sneaky
example.com TXT "v=spf1 ip:0.0.0.0/1 ip:128.0.0.0/1 -all"


On Thu, Apr 14, 2016 at 1:22 PM, Brandon Long via mailop 
wrote:

> What, you don't want to trust all of Apple's /8?
>
> Anyways, adding spf for an entire cloud provider of generic tools seems
> like a really bad idea.  We have to make sure with ours that we don't let
> people cross domain forge, since they may then spf pass... If you don't
> control the software, it is unlikely you can really control that ... Unless
> you control the relay or DPI or something.
> On Apr 14, 2016 11:16 AM, "Michael Peddemors" 
> wrote:
>
> SPF is a decent tool, however it always surprises me when banks open their
> SPF records to the point where they are at risk.  In just the last couple
> of days, we see a couple of banks adding to their SPF records, 'all IP(s)
> in our cloud providers network /16'.
>
> Now, (in the latest case most of MicroSoft's Azure) maybe that is what
> they are recommended to do, however anyone else using those IP(s) is now in
> a perfect position to take advantage of this..
>
> :(
>
>
>
> --
> "Catch the Magic of Linux..."
> 
> Michael Peddemors, President/CEO LinuxMagic Inc.
> Visit us at http://www.linuxmagic.com @linuxmagic
> 
> A Wizard IT Company - For More Info http://www.wizard.ca
> "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
> 
> 604-682-0300 Beautiful British Columbia, Canada
>
> This email and any electronic data contained are confidential and intended
> solely for the use of the individual or entity to which they are addressed.
> Please note that any views or opinions presented in this email are solely
> those of the author and are not intended to represent those of the company.
>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] TLS verify=FAIL

[Franck Martin via mailop]

Client certificates in emails are not rare, even to the contrary, they are
predominant. The proportion of verifiable client certificates is about the
same proportion of verifiable server certificates.

I think there are a few MTAs that have different config for certificate
presented as a client vs a receiver.

For instance postfix has a different config and says not to use client
certs, I tend to disagree. This advice may have been written in the early
days of STARTTLS. The world has changed, especially after Snowden.

http://www.postfix.org/TLS_README.html#client_cert_key

On Thu, Apr 14, 2016 at 8:23 AM, Al Iverson 
wrote:

> Thanks for that. :)
>
> --
> Al Iverson
> www.aliverson.com
> (312)725-0130
>
>
> On Thu, Apr 14, 2016 at 3:02 AM, Steve Freegard 
> wrote:
> >
> > On 14/04/16 00:58, Al Iverson via mailop.org wrote:
> >>
> >> Boo @ designing something so that "FAIL is really nothing is to be
> >> concerned with."
> >>
> >> It's the kind of thing deliverability people will now be spending the
> >> rest of their lives explaining to clients that this big ole FAIL is to
> >> be ignored.
> >>
> >
> > Agreed - which is why it's been changed now.
> >
> > Cheers,
> > Steve.
> >
> >
> > ___
> > mailop mailing list
> > mailop@mailop.org
> > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Gmail Blacklisting

[Franck Martin via mailop]

You can't force your customers, but you have to tell them what will happen
to their emails.

You can point them to this document:
https://www.m3aawg.org/sites/maawg/files/news/M3AAWG_Inbound_IPv6_Policy_Issues-2014-09.pdf

and also
https://engineering.linkedin.com/email/sending-and-receiving-emails-over-ipv6

On Thu, Apr 14, 2016 at 8:26 AM, Thomas Wilhelm 
wrote:

> Hi Brandon,
>
> thank you for your answer.
>
> Our outgoing IPv6-addresses are:
>
> 2a01:5c0:63:10[0-8]::1/56 and
> 2a01:5c0:63:[1-8]::1/56
>
> Our main domains are: inexio.net and myquix.de These domains are under
> our control, so we are going to enable DKIM for both and SPF for
> inexio.net. SPF is already enabled for myquix.de.
>
> In addition to our private customers, we have about 1.000 business
> customers, who also send mails from their domains using our outgoing
> mailserver as a smarthost.
> We can't force them to setup SPF or DKIM for their domains.
>
> I've just enabled maildelivery via IPv6 now for 20% of our mails.
> As soon as I have an example for actual deliviery problems I'm going to
> send you these source domains.
>
> Are there any general improvements we can do ?
>
> best regards,
>
> Thomas
>
> --
> *Von: *"Brandon Long" 
> *An: *"Franck Martin" 
> *CC: *"Tony Finch" , "mailop" , "Thomas
> Wilhelm" 
> *Gesendet: *Mittwoch, 13. April 2016 20:56:31
> *Betreff: *Re: [mailop] Gmail Blacklisting
>
> We don't just run reputation on IP addresses, the spammer killed the
> reputation of any associated domains and such.  Your domain is recovering,
> but it can take up to 30 days to fully recover sometimes longer if
> people don't mark your mail as not spam.
> Though, that's only for the domain you're posting from, without details
> not much more I can go on.
>
> Brandon
>
> On Wed, Apr 13, 2016 at 10:48 AM, Franck Martin via mailop <
> mailop@mailop.org> wrote:
>
>> And it is not only to Google, many other mail receivers requires SPF or
>> DKIM over IPv6.
>> And if you set up a mail receiver with IPv6, do these requirements too,
>> it is an industry best practice (cf M3AAWG.org).
>>
>> On Wed, Apr 13, 2016 at 2:59 AM, Tony Finch  wrote:
>>
>>> Thomas Wilhelm  wrote:
>>> >
>>> > Does anybody have a hint for us, how to fix this problem?
>>>
>>> To send mail to Google over v6 you have to have SPF, DKIM, reverse DNS,
>>> everything set up to the best anti-spam standards.
>>>
>>> Tony.
>>> --
>>> f.anthony.n.finchhttp://dotat.at/  -  I xn--zr8h
>>> punycode
>>> Southeast Iceland: Northeasterly 5 or 6 becoming variable 3 or 4, then
>>> cyclonic 5 to 7. Moderate or rough, becoming slight or moderate for a
>>> time.
>>> Showers. Good.
>>>
>>> ___
>>> mailop mailing list
>>> mailop@mailop.org
>>> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>>>
>>
>>
>> ___
>> mailop mailing list
>> mailop@mailop.org
>> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>>
>>
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

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

[Franck Martin via mailop]

I checked my system, cannot see any report being generated. So may be this
domain name is not in the RFC5322.From ?

On Thu, Apr 14, 2016 at 8:05 AM, Michael Wise 
wrote:

> DMARC is not something I'm well-versed in, but was trying to do what tests
> I could. Would be interesting to see what would happen if someone
> deliberately tried to send from a non-SPF valid IP.
>
> Normally, it just sorta works, but I've never actually seen the traffic it
> generates, or seen the software that is supposed to send it, so I'm unsure
> exactly how to poke it with a stick... :(
>
> Aloha,
> Michael.
> --
> Sent from my Windows Phone
> --
> From: Dickie LaFlamme 
> Sent: ‎4/‎14/‎2016 5:55 AM
> To: Michael Wise 
>
> Cc: mailop@mailop.org
> Subject: Re: [mailop] DMARC record in p=none not receiving aggregate
> reports to RUA
>
> My bad, I should have included this issue has spanned well over multiple
> days so the 24 hours rule wasn't a cause.
>
> I queued a few different customers I know with valid DMARC records and I'm
> seeing the  “\” in front of the “;”’s.
>
> I will however dig into the greylisting. As always, thank you all for
> looking into this and helping out!
>
> Thanks,
>
> [image: Dyn logo, Dyn.com]
> 
>
> 
>
> [image:
> Dyn facebook account]
> 
>
> [image:
> Dyn LinkedIn account]
> 
>
> Dickie LaFlamme / Deliverability Specialist
>  +1 603-296-1952
>
> On Wed, Apr 13, 2016 at 9:22 PM, Michael Wise 
> wrote:
>
>>
>>
>> I see it slightly differently:
>>
>>
>>
>> $ host -t txt _dmarc.chinalovecupid.com
>> 
>>
>> _dmarc.chinalovecupid.com
>> 
>> descriptive text "v=DMARC1\; p=none\; rua=mailto:dm...@chinalovecupid.com
>> "
>>
>>
>>
>> What’s with the “\” in front of the “;”’s?
>>
>>
>>
>> Aloha,
>>
>> Michael.
>>
>> --
>>
>> *Michael J Wise* | Microsoft | Spam Analysis | "Your Spam Specimen Has
>> Been Processed." | Got the Junk Mail Reporting Tool
>> 
>> ?
>>
>>
>>
>> *From:* Dickie LaFlamme [mailto:rlafla...@dyn.com]
>> *Sent:* Wednesday, April 13, 2016 6:02 PM
>> *To:* Michael Wise 
>> *Cc:* mailop@mailop.org
>> *Subject:* Re: [mailop] DMARC record in p=none not receiving aggregate
>> reports to RUA
>>
>>
>>
>> ha, no worries. That's fair enough. Here's the customers DMARC record.
>>
>> The domain
>>
>> ​:​
>>
>> chinalovecupid.com
>> 
>>
>> v=DMARC1; p=none; rua=mailto:dm...@chinalo

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

[Franck Martin via mailop]

DMARC looks ok:
https://dmarcian.com/dmarc-inspector/chinalovecupid.com

Sometimes it takes more than 24 hours, also make sure the mail system does
not flag the report as spam (because containing bad IPs)...

On Wed, Apr 13, 2016 at 6:22 PM, Michael Wise 
wrote:

>
>
> I see it slightly differently:
>
>
>
> $ host -t txt _dmarc.chinalovecupid.com
>
> _dmarc.chinalovecupid.com descriptive text "v=DMARC1\; p=none\;
> rua=mailto:dm...@chinalovecupid.com";
>
>
>
> What’s with the “\” in front of the “;”’s?
>
>
>
> Aloha,
>
> Michael.
>
> --
>
> *Michael J Wise* | Microsoft | Spam Analysis | "Your Spam Specimen Has
> Been Processed." | Got the Junk Mail Reporting Tool
>  ?
>
>
>
> *From:* Dickie LaFlamme [mailto:rlafla...@dyn.com]
> *Sent:* Wednesday, April 13, 2016 6:02 PM
> *To:* Michael Wise 
> *Cc:* mailop@mailop.org
> *Subject:* Re: [mailop] DMARC record in p=none not receiving aggregate
> reports to RUA
>
>
>
> ha, no worries. That's fair enough. Here's the customers DMARC record.
>
> The domain
>
> ​:​
>
> chinalovecupid.com
> 
>
> v=DMARC1; p=none; rua=mailto:dm...@chinalovecupid.com
>
>
>
> ​Again we know that this does not currently have the ​"pct=100" tag, but
> with or without the results have been the same.
>
>
>
>
> Thanks,
>
> [image: Image removed by sender. Dyn logo, Dyn.com]
> 
>   [image: Image removed by sender.]
> 
>
> [image:
> Image removed by sender. Dyn facebook account]
> 
>
> [image:
> Image removed by sender. Dyn LinkedIn account]
> 
>
> Dickie LaFlamme / Deliverability Specialist
> [image: Image removed by sender.] +1 603-296-1952
>
>
>
> On Wed, Apr 13, 2016 at 8:43 PM, Michael Wise 
> wrote:
>
>
>
> … as always, please let us know the customer’s real domain name (or IP
> address, or whatever) when making these requests.
>
>
>
> Not including that is about on par with the legendary complaints of:
>
>
>
> “ It Doesn’t Work.
>
> “ I Can’t Print.
>
> Etc,
>
>
>
> At some point, we’re going to ask you for it anyway, so best to just
> provide it at the start.
>
>
>
> Aloha,
>
> Michael.
>
> --
>
> *Michael J Wise* | Microsoft | Spam Analysis | "Your Spam Specimen Has
> Been Processed." | Got the Junk Mail Reporting Tool
> 
> ?
>
>
>
> *From:* mailop [mailto:mailop-boun...@mailop.org] *On Behalf Of *Dickie
> LaFlamme
> *Sent:* Wednesday, April 13, 2016 5:28 PM
> *To:* mailop@mailop.org
> *Subject:* [mailop] DMARC record in p=none not receiving aggregate
> reports to RUA
>
>
>
> We have a customer who's setup a DMARC record with the correct TXT record;
> v=DMARC1; p=none; pct=100; rua=mailto:dmarc@"customerspostmaster"; after
> waiting the 24 hour period we still did not receive any aggregate reports
> to the mailbox. After some searching we advised the customer to try and
> take out "PCT" as that could possibly have been triggering something to not
> work corr

Re: [mailop] TLS verify=FAIL

[Franck Martin via mailop]

Have a look at
https://tools.ietf.org/html/draft-martin-authentication-results-tls-03 may
be jump to the example...

I did not pursue, but many MTA clients are sending the certificates, meant
for receiving email to the server they are connecting too.

You can verify that the certificate is trusted (based on your list of
trusted CAs), but there are no good method to do hostname verification. May
be a FCrDNS would allow you to compare with the DNS names in the
SubjectAltNames of the certificate...

On Wed, Apr 13, 2016 at 4:58 PM, Al Iverson 
wrote:

> Boo @ designing something so that "FAIL is really nothing is to be
> concerned with."
>
> It's the kind of thing deliverability people will now be spending the
> rest of their lives explaining to clients that this big ole FAIL is to
> be ignored.
>
> --
> Al Iverson
> www.aliverson.com
> (312)725-0130
>
>
> On Wed, Apr 13, 2016 at 5:33 PM, Steve Freegard 
> wrote:
> > Hi Robert,
> >
> > I'm one of the developers of Haraka.
> >
> > verify=FAIL simply means that the TLS certificate presented by the peer
> host
> > could not be verified as trusted by a CA.
> > In the case of an MUA (which this appears to be), it would be normal as
> an
> > MUA does not usually present client TLS certificates, so this would
> always
> > be expected to fail verification because we have no certificate to verify
> > against, so I changed this in the latest alpha say verify=NO meaning we
> > couldn't verify the certificate as one wasn't presented.
> >
> > Your logs will provide more information e.g.:
> >
> > haraka[1124]: [INFO] [E11963C4-DB93-4F29-BC81-E066E3D3D369]
> [defendermx/tls]
> > secured: cipher=ECDHE-RSA-AES256-SHA38
> > 4 version=TLSv1/SSLv3 verified=false error="Error: unable to get issuer
> > certificate"
> >
> > haraka[12586]: [INFO] [60ACFC0C-7DD8-4A3C-85F7-ED21F673E23F]
> > [defendermx/tls] secured: cipher=ECDHE-RSA-AES128-GCM-SHA256
> > version=TLSv1/SSLv3 verified=true cn="smtp.gmail.com"
> organization="Google
> > Inc" issuer="Google Inc" expires="Oct 12 00:00:00 2016 GMT"
> > fingerprint=41:D4:85:E1:FC:1B:1D:3A:2D:60:E3:51:AB:E6:4A:A4:52:D8:CF:00
> >
> > In short - it's really nothing to be concerned with.
> >
> > Kind regards,
> > Steve.
> >
> >
> >
> > On 13/04/16 22:56, Robert Guthrie via mailop.org wrote:
> >
> > Hello List,
> >
> > I wonder if someone could tell me about the verify=FAIL messages I'm
> seeing
> > in email headers sent from my SMTP's.
> >
> > Received: from loomio.io (errbit.loomio.org [45.55.128.240])
> >   by smtp.loomio.io (Haraka/2.8.0-alpha.7) with ESMTPSA id
> > 632790F7-CF56-4481-ACBA-2CBACE7EB8BB.1
> >   envelope-from  (authenticated bits=0)
> >   (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384
> verify=FAIL);
> >   Wed, 13 Apr 2016 21:05:59 +
> >
> > If I'm seeing this, is there something I can or should do to resolve
> this?
> > Sometimes I see verify=NO also.
> >
> >
> > ___
> > 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
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] How long does an IP address take to "Warm up"?

[Franck Martin via mailop]

I take the rule of thumb that hotmail/outlook.com does not like more than
20% volume changes day over day and week over week. Subscribe to the SNDS,
and if you see your IPs in the yellow, stop ramping up. All the other
mailbox providers follow same rules more or less, but this gives you a fair
control of your ramping up.

On Wed, Apr 13, 2016 at 1:15 PM, Robert Guthrie  wrote:

> Wow. Thanks for the really helpful replies List.
>
> As of this morning I'm not seeing the delays anymore. The IP has been in
> use as our main SMTP for 13 days from a cold start.
>
> The old, warmed up IP address is long gone - back to the VPS provider. I
> know now that that was a Rookie mistake - For a long time I was
> misunderstanding my error messages, and I thought that somehow my old
> (warmed up) IP address had been blacklisted, but actually I had the Haraka
> dnsbl plugin enabled, and it was rejecting because my worker dyno on Heroku
> was blacklisted (I assume for being used to send spam by a previous admin).
>
> I have DKIM, SPF, TLS all configured on this instance. I saw delays start
> out at about 8 hours and reduce to about 40 minutes until they disappeared
> today.
>
> I'm going to publish a blog post about my experiences trying to setup an
> SMTP using Haraka so hopefully some people can learn from my mistakes.
>
>
>
>
>
> On Thu, 14 Apr 2016 at 07:53 G. Miliotis  wrote:
>
>> On 13/4/2016 22:28, Brandon Long via mailop wrote:
>> > if you have sufficient volume and your mail authenticates and you keep
>> > the same authentication when switching IPs, then your reputation
>> > should transfer.
>> Does this mean having the same DKIM key or something else?
>>
>> --GM
>>
>> ___
>> mailop mailing list
>> mailop@mailop.org
>> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Gmail Blacklisting

[Franck Martin via mailop]

And it is not only to Google, many other mail receivers requires SPF or
DKIM over IPv6.

And if you set up a mail receiver with IPv6, do these requirements too, it
is an industry best practice (cf M3AAWG.org).

On Wed, Apr 13, 2016 at 2:59 AM, Tony Finch  wrote:

> Thomas Wilhelm  wrote:
> >
> > Does anybody have a hint for us, how to fix this problem?
>
> To send mail to Google over v6 you have to have SPF, DKIM, reverse DNS,
> everything set up to the best anti-spam standards.
>
> Tony.
> --
> f.anthony.n.finchhttp://dotat.at/  -  I xn--zr8h
> punycode
> Southeast Iceland: Northeasterly 5 or 6 becoming variable 3 or 4, then
> cyclonic 5 to 7. Moderate or rough, becoming slight or moderate for a time.
> Showers. Good.
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Gmail red open padlock composing message

[Franck Martin via mailop]

On Sat, Apr 2, 2016 at 10:40 AM, Carl Byington  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On Sat, 2016-04-02 at 11:42 -0500, frnk...@iname.com wrote:
> > Anyone aware of email servers that take the approach that CloudFlare
> > has, which is not allow the lowest common denominator or cleartext to
> > be used if there's a better/more-secure cipher, but still support the
> > old stuff (in CloudFlare's case, SHA-1) if that's all it can do?
>
> > https://blog.cloudflare.com/sha-1-deprecation-no-browser-left-behind/
>
> I think that is "server preference" for the cipher ordering.
>
> https://github.com/jvehent/cipherscan
>
> For example, gmail (on incoming mail) supports RC4-MD5 over ssl3, and
> they also have the server control the cipher ordering. But please, why
> do they prefer RC4-MD5/TLS1.2 over ECDHE-RSA-AES256-GCM-SHA384/TLSv1.2
> ?? I don't understand that. Google might know that the only clients that
> ask for rc4-md5 don't support anything better.
>
> My notes say that Outlook 2011 on Mac OSx needs sslv3/rc4-sha.
>
> Sendmail with a modern openssl:
>
> LOCAL_CONFIG
> dnl enable sslv3 on the server side for RC4-SHA
> O CipherList=...whatever you want
> O ServerSSLOptions=+SSL_OP_NO_SSLv2 +SSL_OP_CIPHER_SERVER_PREFERENCE
> O ClientSSLOptions=+SSL_OP_NO_SSLv2 +SSL_OP_NO_SSLv3
>
> We support sslv3 on incoming connections, but not on outgoing
> connections.
>
>
Well, you can have two different policies for SMTP and SUBMISSION, where
SUBMISSION needs to be a bit more relax to support all the clients out
there, like Outlook 2011...
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Gmail red open padlock composing message

[Franck Martin via mailop]

RC4 is a conundrum, it is about the only cypher you can negotiate with old
MS-Exchange, so if you disable it, then the email will go in clear text.
Which one is better? Clear text or RC4? Or too bad for old mail servers?

PFS or Elliptic ciphers are asymmetric in implementation, so you need to
check what's negotiated as a sender and as a receiver.

Finally it seems some systems do not fall back anymore, if you initiate
STARTTLS and can't negotiate it, then you can't send email in clear text.

And then look at SMTP STS

On Fri, Apr 1, 2016 at 6:00 AM, Kirk MacDonald <
kirk.macdon...@corp.eastlink.ca> wrote:

> Whoops, I fully intended to audit the available ciphers; clearly I missed
> doing that. Should be OK now.
>
> Tragically, PFS is not (yet) supported on the TLS mechanism I am making
> use of. I hope to be able to change that in the somewhat near future.
>
>
> -Original Message-
> From: Tim Bray [mailto:t...@kooky.org]
> Sent: Friday, April 01, 2016 5:58 AM
> To: Kirk MacDonald ; mailop@mailop.org
> Subject: Re: [mailop] Gmail red open padlock composing message
>
> On 31/03/16 17:38, Kirk MacDonald wrote:
> > With thanks to Google for pushing the cause, I implemented STARTTLS
> > functionality on my org’s MX (as well as outbound SMTP with
> > opportunistic STARTTLS).
>
>
> Firstly - well done for doing it.   Everybody should be enabling TLS.
>
> Did you test the install?
>
> You have TLS, but there are some issues with your setup:
>
> https://ssl-tools.net/mailservers/corp.eastlink.ca
>
> So you need to disable the RC4 cipher.  Everybody suggests it is insecure.
>
> Also you don't support the correct ciphers for Perfect Forward Secrecy.
>
>
> I'm not sure whether this affects whether google shows the padlock or
> not.  Best practice is to get it fixed.
>
> I think ssl-tools.net is the best test for TLS mailservers.  You can
> test your mail sending as well.
>
>
> For webservers, use https://www.ssllabs.com/ssltest/ to test.  There is
> also a tool to help make good configs at
> https://mozilla.github.io/server-side-tls/ssl-config-generator/
>
> What I've realised over the last year or so is that SSL/TLS isn't
> something you can just fiddle with until it works.  If you want it
> secure, across all browsers, it needs some work.
>
> https://www.feistyduck.com/books/bulletproof-ssl-and-tls/  is an
> excellent book.
>
>
> Tim
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Use of Message Disposition Notification in the wild

[Franck Martin via mailop]

MDN are ugly and look like garbage to the receiver ;) How many times I had
to fight back the urge of people to send back a real email instead of a
reject code...

Also on postfix the RFC5322.From: set in the templates does not contain an
email address with a domain name, which you need to fix, when doing DMARC.

Now, going to read this draft, and thank you for trying to improve this
area.

On Fri, Apr 1, 2016 at 6:26 AM, Alexey Melnikov 
wrote:

> Hi,
> This might be slightly off-topic for this group, but I hope this post is
> still relevant here. I am finishing updating a revision to RFC 3798
> (Message Disposition Notification), currently specified in
> draft-ietf-appsawg-mdn-3798bis-06.txt.
>
> If you have experience using (generating, processing) MDNs and deployed
> any extensions to the format, I would like to hear about that. I would also
> like to hear if anybody is trying to convey non-ASCII information (such as
> non-ASCII Failure/Error fields, mail user agent information, gatewaying of
> addresses to other environments) and what encodings are used for that.
>
> Thank you,
> Alexey
>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Gmail red open padlock composing message

[Franck Martin via mailop]

I wanted to add, make sure you have compatible ciphers, you may have
enabled STARTTLS but if you cannot negotiate a cypher, then the point is
moot ;)

A packet capture when STARTTLS is initiated will tell you what ciphers are
offered and which one is negotiated.

On Thu, Mar 31, 2016 at 12:03 PM, Franck Martin 
wrote:

> I guess, once they have positive data on your domain, they should update
> the icon:
> https://www.google.com/transparencyreport/saferemail/#search=eastlink.ca
>
> On Thu, Mar 31, 2016 at 9:38 AM, Kirk MacDonald <
> kirk.macdon...@corp.eastlink.ca> wrote:
>
>> With thanks to Google for pushing the cause, I implemented STARTTLS
>> functionality on my org’s MX (as well as outbound SMTP with opportunistic
>> STARTTLS).
>>
>>
>>
>> Does anyone have any insight into how long it might take Gmail to
>> acknowledge the STARTTLS availability when composing a new message to a
>> domain at my org, and consequently not show the red unlocked padlock in the
>> compose message UI?
>>
>>
>>
>> I am assuming that for “known” domains Gmail caches results for STARTTLS
>> availability, rather than testing each time a message is composed. The TTL
>> in DNS for the MX record of the domain(s) has long since passed. My own
>> personal testing seems to indicate I didn’t do anything terribly stupid
>> when implementing STARTTLS at the MX.
>>
>>
>>
>>
>>
>> *Kirk MacDonald System Administrator*
>> Internet
>> Eastlink
>>
>>
>>
>> ___
>> mailop mailing list
>> mailop@mailop.org
>> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>>
>>
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Gmail red open padlock composing message

[Franck Martin via mailop]

I guess, once they have positive data on your domain, they should update
the icon:
https://www.google.com/transparencyreport/saferemail/#search=eastlink.ca

On Thu, Mar 31, 2016 at 9:38 AM, Kirk MacDonald <
kirk.macdon...@corp.eastlink.ca> wrote:

> With thanks to Google for pushing the cause, I implemented STARTTLS
> functionality on my org’s MX (as well as outbound SMTP with opportunistic
> STARTTLS).
>
>
>
> Does anyone have any insight into how long it might take Gmail to
> acknowledge the STARTTLS availability when composing a new message to a
> domain at my org, and consequently not show the red unlocked padlock in the
> compose message UI?
>
>
>
> I am assuming that for “known” domains Gmail caches results for STARTTLS
> availability, rather than testing each time a message is composed. The TTL
> in DNS for the MX record of the domain(s) has long since passed. My own
> personal testing seems to indicate I didn’t do anything terribly stupid
> when implementing STARTTLS at the MX.
>
>
>
>
>
> *Kirk MacDonald System Administrator*
> Internet
> Eastlink
>
>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] yahoo feedback loop signup?

[Franck Martin via mailop]

DKIM is relatively easy to do, just get on with the program...

It seems very unlikely that for 50 messages a day, Yahoo would spend some
resources to help you not to have to spend some resources to enable DKIM.

On Mon, Mar 28, 2016 at 3:08 PM, Carl Byington  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> I am trying to help a very small isp with a yahoo.com delivery issue.
> They are getting "421 4.7.0 [TS02] Messages from 208.88.52.225
> temporarily deferred - 4.16.56.1; see
> http://postmaster.yahoo.com/errors/421-ts02.html"; errors.
>
> Volume is less than 50 total messages per day going to yahoo.com
> addresses. Clients use their own domain names.
>
> https://help.yahoo.com/kb/account/yahoo-complaint-feedback-loop-
> service-faq-sln26007.html says "For bulk commercial senders or senders
> of transactional mail, DomainKeys or DKIM is the best option. ISPs
> should contact Yahoo for other options.", but gives no contact address
> for an ISP. Is that a mistake? Is the Yahoo feedback loop only available
> for folks that DKIM sign outbound mail?
>
>
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.14 (GNU/Linux)
>
> iEYEAREKAAYFAlb5qy0ACgkQL6j7milTFsHaOQCbBS7FforwdSURhEDfSn9p6ujK
> n+wAoIFRSmuzrqFH+pmcHDS5luzS5koJ
> =79zs
> -END PGP SIGNATURE-
>
>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Yahoo DMARC changes

[Franck Martin via mailop]

SMTP AUTH With or without OAUTH  (aka Submission) is the same functionally.
The difference is with OAUTH2 you don't have to share your password with
the ESP.

On Thu, Mar 24, 2016 at 7:09 AM, Suresh Ramasubramanian  wrote:

> If you are confident that all your customers doing this are low volume and
> legit, and none of them will ever be compromised, be my guest
>
> --srs
>
> > On 24-Mar-2016, at 7:27 PM, G. Miliotis 
> wrote:
> >
> > Now if you are suggesting that they will see multiple different logins
> on their SMTP from the same IP address, yes they will. If they consider
> this an attempt at spamming, i.e. I've harvested logins via phishing and am
> sending spam, maybe they should improve their filters.
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Yahoo DMARC changes

[Franck Martin via mailop]

In fact, these providers offer OAUTH2 to allow you to send as using their
infrastructure, and if you have bigger needs, many domains are going cheap
at the moment...

Not ideal, but some options...

On Wed, Mar 23, 2016 at 3:45 PM, Steve Atkins  wrote:

>
> > On Mar 23, 2016, at 3:16 PM, Joel Beckham  wrote:
> >
> >
> > It's likely that ARC will become the new - much better - workaround
> eventually, modulo the inevitable deployment issues. http://arc-spec.org
> >
> > I thought that ARC doesn't help with the ESP use case, or am I missing
> something there?
>
> Probably not, no. The long term answer there is probably much the same as
> the short term one - declining to send mail "from" users of those consumer
> ISPs who've published p=reject records, and encouraging them to get an
> email address elsewhere (whether that be an email address controlled by the
> ESP or one from a more appropriate mailbox provider).
>
> Cheers,
>   Steve
>
>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Google DNS Servers not returning results for Hotmail today?

[Franck Martin via mailop]

The outage is listed at https://ianix.com/pub/dnssec-outages.html

On Tue, Mar 8, 2016 at 6:21 AM, Vick Khera  wrote:

>
> On Mon, Mar 7, 2016 at 6:00 PM, Carl Byington 
> wrote:
>
>> Yes, arin.net
>>
>> failed to renew the dnssec signatures on 65.in-addr.arpa.
>> They have expired, and anyone behind a dnssec enforcing resolver can no
>> longer see ptr records in that tree.
>>
>
> Looks to be corrected now. It resolves for both my own recursive resolver
> which enforces DNSSEC as well as 8.8.8.8.
>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] TLS/SSL DROWN attack with respect to email servers

[Franck Martin via mailop]

On Wed, Mar 2, 2016 at 5:29 PM, Brandon Long  wrote:

> I thought that POODLE required a specific type of fallback that tended to
> be browser specific (ie, prevent a tls connection, forcing the browser to
> fall back to a ssl3 connection), do any smtp servers actually do that?
>

Re-negotiation is part of SSL/TLS I believe, so once STARTTLS is initiated,
I believe you can create the right conditions to fall back to SSLv3.

This tool is cool for finding issues on mail servers
https://ssl-tools.net/mailservers
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] TLS/SSL DROWN attack with respect to email servers

[Franck Martin via mailop]

Disable SSLv3 too, because of Poodle.

We will need to get rid of RC4, unfortunately this is the only cypher some
old exchange machines understand. Also falling back to clear text from
STARTTLS is more and more frowned upon.

On Wed, Mar 2, 2016 at 1:45 PM, Matthew Huff  wrote:

> If your mail server still is advertising SSLv2, you SSL private key may be
> vulnerable.
>
> https://www.us-cert.gov/ncas/current-activity/2016/03/01/SSLv2-DROWN-Attack
>
> What's worse, if you are using a wildcard cert, then any other server that
> is using the same cert can be trivially decrypted even if that server is
> only using TLS1.2 and strong cyphers.
>
> I know that there are a number of broken email servers that will bounce
> mail if TLS is negotiated but they can't negotiate older SSL  or weaker
> cyphers, but it's probably a good idea to either: 1) Disable TLS, or 2)
> Disable SSLv2
>
> 
> Matthew Huff | 1 Manhattanville Rd
> Director of Operations   | Purchase, NY 10577
> OTA Management LLC   | Phone: 914-460-4039
> aim: matthewbhuff| Fax:   914-694-5669
>
>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] proper NULL MX behaviour for MTAs?

[Franck Martin via mailop]

On Sat, Feb 27, 2016 at 7:23 PM, Mark Jeftovic  wrote:

>
> On 2016-02-27 9:59 PM, Suresh Ramasubramanian wrote:
> > A domain with a null mx may well originate email but will absolutely not
> receive email - so mail gets trashed at your end as well without staying
> endlessly on your mall queues
> >
> > You can possibly correlate that mx with the behavior of domains that are
> sending you mail.. Though a domain rather than IP bl may make sense.
> >
>
> Sorry, I realized after I sent that I needed to clarify that what I'm
> observing are MTAs attempting to deliver email to addresses at IP of the
> A record for the domain, ignoring the presence of its NULL MX.
>
> So the originating MTAs are ignoring the NULL MX and attempting to
> deliver to the A hostname, leading me to surmise they are spambots or
> zombies.
>

This could be true but then RFC7505 is recent, so I'm not sure that proper
MTAs are yet properly behaving. I wonder what sendmail, postfix, exim
really do?
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] proper NULL MX behaviour for MTAs?

[Franck Martin via mailop]

If a domain is telling me it does not accept emails, why should I accept
mail from such domain if I cannot reply back to it?

On Sat, Feb 27, 2016 at 6:59 PM, Suresh Ramasubramanian  wrote:

> A domain with a null mx may well originate email but will absolutely not
> receive email - so mail gets trashed at your end as well without staying
> endlessly on your mall queues
>
> You can possibly correlate that mx with the behavior of domains that are
> sending you mail.. Though a domain rather than IP bl may make sense.
>
> --srs
>
> > On 28-Feb-2016, at 8:07 AM, Mark Jeftovic  wrote:
> >
> >
> > What is an MTA supposed to do with a message addressed to a domain with
> > a NULL MX?
> >
> > RFC 7505 talks about domains with a NULL MX should not originate email
> > (in their sender envelopes, etc) but what about the converse?
> >
> > I'm looking at some logs and seeing attempts to deliver email to lots of
> > domains with NULL MX enabled (that have been so for years) and wondering
> > if I can safely mine these logs and add all the originating MTA IPs to
> > an internal RBL.
> >
> > I think I can. I think I will.
> >
> > - mark
> >
> > --
> > Mark Jeftovic, Founder & CEO, easyDNS Technologies Inc.
> > Company Website: http://easydns.com
> > Read my blog: http://markable.com
> > +1-416-535-8672 ext 225
> >
> > ___
> > mailop mailing list
> > mailop@mailop.org
> > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Help - Anyone know a GitHub People

[Franck Martin via mailop]

Well,

This is not a friendly welcome...

Please you have an opportunity to engage and get things fixed, so don't
throw a ton of bricks on the first email.

Thanks.

On Thu, Feb 25, 2016 at 4:25 AM, Rich Kulawiec  wrote:

> On Thu, Feb 25, 2016 at 07:17:56PM +0800, ?? wrote:
> > I am a postmaster of Netease Inc.(NASDAQ: NTES), we are a professional
> > email service provider in China with domains 163.com, 126.com, yeah.net
> > and etc.
>
> I can't speak for GitHub, but I've had most of those domains blacklisted
> for over a decade because of (a) nonstop spam, phishing, and other forms
> of email abuse (b) failure to respond to abuse reports (c) failure to
> support RFC-2142 mandated role addresses.
>
> ---rsk
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

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

[Franck Martin via mailop]

I suspect with ARC coming up, leaving traces of broken DKIM headers will be
useful.

On Mon, Feb 22, 2016 at 1:35 PM, Al Iverson 
wrote:

> On Mon, Feb 22, 2016 at 2:48 PM, Jim Popovitch  wrote:
> > On Mon, Feb 22, 2016 at 1:46 PM, John Levine  wrote:
>  IMHO, Mailman should strip the existing DKIM header and Mailop.org
> should sign anew.
> >>>
> >>>Yes!  That is the perfect and proper way, despite some rants by less
> >>>experienced mailinglist operators.
> >>
> >> Hi.  I've been running mailing lists since the late 1970s and having
> >> actually read the DKIM specs and written a fair amount of DKIM code, I
> >> know that stripping signatures makes no difference unless someone's
> >> mail filters are breathtakingly broken.
> >
> > But leaving the DKIM signatures provides what actual value with modern
> > MLMs (i.e. not .forward files, etc.)  ?
>
> I'm going to say it's an irrelevant question, because even just the
> headers that I excerpted in the thread are enough to suggest that John
> and Google might disagree on what constitutes broken.
>
> Regards,
> Al
>
> --
> Al Iverson
> www.aliverson.com
> (312)725-0130
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] yahoo appears to be blocking one of our entire base hostnames causing mail problems with hundreds of servers

[Franck Martin via mailop]

You may want to add to the public suffix list your domain. This will
indicate to many people where the delimitation on administration of domains
lies.

https://publicsuffix.org/

Check entries for blogspot, azure, to have an idea what you need to submit.

On Fri, Feb 19, 2016 at 4:41 AM, Jayme  wrote:

> So we have hundreds of shared and dedicated cPanel servers that use the
> same domain for the base hostname i.e. server.validns.com,
> server2.validns.com etc.
>
> We started to get complaints from users across multiple servers that yahoo
> mail was being rejected with:
>
> SMTP error from remote mail server after end of data: 554 Message not
> allowed - [PH01] Email not accepted for policy reasons. Please visit
> http://postmaster.yahoo.com/errors/postmaster-27.html [120]
>
> This is happening across many servers on different IPs regardless of the
> sending domain, dkim/spf etc. It's basically happening to anyone sending
> mail to @yahoo.com on any server that is using the validns.com. We have
> multiple other servers on different base hostnames on the same IP block
> that don't seem to be affected.
>
> So I did some looking in to this and eventually I found a complaint about
> a phishing attempt on our hostname coming from serverX.validns.com. A
> clients site got hacked and phishing scripts uploaded to it and they were
> being called using the server hostname i.e.
> serverX.validns.com/~cpaneluser/hack -- this somehow led to the entire
> validns.com being listed on SURBL multi. I have no idea why they listed
> the entire domain VS the full hostname the source was coming from I.e.
> instead of listing serverX.validns.com they listed validns.com.  Fast
> forward, I cleaned up the phishing and submitted a removal request to SURBL
> mutli and the domain was delisted over 2 days ago and shows good status in
> their lookup. Ever since Yahoo seems to have not dropped the listing or
> whatever they are using internally that is causing them to reject all
> messages from any server using this hostname.
>
> Is it possible that yahoo.com picked up on the SURBL listing and are
> blocking our entire hostname based on it? I was hoping if so they'd drop it
> by now seeing as the listing was removed over 2 days ago, but so far no
> such luck. Or is it possible that our validns.com could be listed in some
> other URBL that yahoo could be picking up on? So far I've got it off SURBL
> multi, checked it on spamhaus DBL and uribl.com and it's not listed on
> either of those. There may be others I'm not aware of.
>
> Right now we have hundreds of servers and thousands of users on them that
> are unable to mail to yahoo.com and it's causing a huge support mess. It
> almost seems impossible to get hold of anyone that can actually help with
> the problem at yahoo, I've send emails and forms, everything I can find but
> no response back yet.
>
> If whatever block yahoo has on our hostname continues I don't know what
> else to do if I can't get a hold of them short of changing the hostnames
> (which would be a huge disaster) or trying to find a way to configure exim
> to route mail destined to yahoo.com through another mail server (I'd have
> to setup one on a different hostname and allow relaying through it) then
> configure all the servers to relay yahoo through it. I'm sure it'd work but
> it's also quite a bit of work as well.
>
> Has anyone ever dealt with a problem like this? I've been in hosting since
> '96 and I can't recall a case where I've ever seen a main hostname get
> listed like this while the source of the problem was on a sub-domain.
>
> Thanks!
>
> James
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

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

[Franck Martin via mailop]

Read the archives and
https://social.technet.microsoft.com/Forums/en-US/c0b76505-8737-4b6e-bcee-62cb1ea5ef96/dkim-automatic-forwarding-to-gmail-dkim-neutral

On Fri, Feb 12, 2016 at 12:14 AM, Renaud Allard via mailop <
mailop@mailop.org> wrote:

>
>
> 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.
>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

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

[Franck Martin via mailop]

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.

On Thu, Feb 11, 2016 at 3:53 AM, Chris Burton  wrote:

> Hi,
>
> > Did anyone notice DKIM issues (mails failing signature verification or
> body
> > hash not matching) with mails coming from these servers?
>
> We're also using exim and seeing signature_incorrect and
> bodyhash_mismatch issues via
>
> emea01-am1-obe.outbound.protection.outlook.com
> emea01-db3-obe.outbound.protection.outlook.com
> EUR01-HE1-obe.outbound.protection.outlook.com
> EUR01-VE1-obe.outbound.protection.outlook.com
> na01-bl2-obe.outbound.protection.outlook.com
> na01-bn1-obe.outbound.protection.outlook.com
>
> And some being relayed out via mimecast.com that show errors
> validating DKIM on a *.onmicrosoft.com sender.
>
> Could this be a similar issue to
> https://bergs.biz/blog/2014/04/10/outlook-com-breaks-dkim-signatures/
> ?
>
> I've only got an outlook.com account to test with (which doesn't use
> DKIM) but relaying an email via smtp-mail.outlook.com without quotes
> on the Content-Type charset they are added in by the time the mail
> reaches our exim server.
>
> Chris.
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Failure reporting false positives to ClamAV

[Franck Martin via mailop]

On Wed, Feb 10, 2016 at 8:10 AM, Michael Peddemors 
wrote:

> That rule has triggered more and more false positives of late BTW..
>
> If you would like to disable this check in the future, you can do so by
> editing /etc/clamav/clamd.conf and setting the following value to false:
>
> PhishingScanURLs
>
> Once done, you will need to restart clamav:
>
> /etc/init.d/clamav-daemon restart
>
>
+1
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

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

[Franck Martin via mailop]

Awesome, many thanks.

(and let's see if it works)

On Tue, Feb 9, 2016 at 12: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
>
>
> --
> Simon Lyall  |  Very Busy  |  Web: http://www.simonlyall.com/
> "To stay awake all night adds a day to your life" - Stilgar
>
>
> ___
> 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