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] 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 <graeme+mai...@graemef.net>
wrote:

> On 9 Jan 2017, at 14:08, Franck Martin via mailop <mailop@mailop.org>
> 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 <r...@fastmail.fm> 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] 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 <mailop@mailop.org
> 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] 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] 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 <mich...@linuxmagic.com>
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] 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] 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 <d...@dotat.at> wrote:

> Franck Martin via mailop <mailop@mailop.org> 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.finch    http://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
> 

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] 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 <thomas.wilh...@inexio.net>
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" <bl...@google.com>
> *An: *"Franck Martin" <fmar...@linkedin.com>
> *CC: *"Tony Finch" <d...@dotat.at>, "mailop" <mailop@mailop.org>, "Thomas
> Wilhelm" <thomas.wilh...@inexio.net>
> *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 <d...@dotat.at> wrote:
>>
>>> Thomas Wilhelm <thomas.wilh...@inexio.net> 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.finch  <d...@dotat.at>  http://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]

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 correctly 

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] 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.finch    http://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]

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] 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]

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] 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] 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