Re: [mailop] Many SPF failures lately

According to the standard, invlid SPF record results in spf=permerror, not in spf=fail. It's up to you to reject the message in this case, but it's definitely not what system administrator of the sending system told you. 16.05.2017 16:20, Michael Orlitzky пишет: > On 05/15/2017 12:34 PM, D'Arcy

Re: [mailop] Many SPF failures lately

It's good practice to read the standard before implementing it. For permerror, 550 with 5.5.2 status code must be used, it's RFC 7208 requirement for one, who decides to block delivery based on SPF error. 451 with 4.4.3 status code should only be used for temperror, such as DNS timeout . Using 4x

Re: [mailop] SPF record

yes and no. Actually, this record may be invalid, depending on the number of MX records for example.org. SPF is limited to 10 name resolutions to resolve policy to final IP addresses. In this case name resolution scenario is: 1. Resolve SPF record itself (1 name resolution) 2. Resolve MX for exma

Re: [mailop] SPF record

DKIM is solution. ARC is not solution and never will. Actually, I see no any reason for ARC, really. If you trust sender, you can trust his Received: without any cryptography. If you do not trust sender, you can not trust ARC regardless of cryptography. ARC doesn't work without trusts. The only

Re: [mailop] dkim signature failures sendmail/opendkim

In most cases, DKIM check fails because message was improperly formatted and was normalized by MTA before sending after DKIM signature is applied. This usually means: - Lines longer than 998 octets (unicode character takes few octets) - Missed Date:, Message-ID: or another required header - Unenc

Re: [mailop] What are "printing ASCII characters" RFC 850/2822

ASCII is 7-bit encoding, it means there can not be ASCII characters with values above 127. 09.06.2017 17:22, Benoit Panizzon пишет: > Hello > > Thank you for the replies suggesting that the problem could be caused > by an amavis virus scanner. That was bullseye :-) > > Indeed, amavis at recipioe

Re: [mailop] dkim signature failures sendmail/opendkim

To normalize the message before signing is a good solution. Switching normalization off does not solve the problem, because receiver can also normalize the message before checking signature. 11.06.2017 19:17, Carl Byington пишет: > On Fri, 2017-05-26 at 18:38 +0300, Vladimir Dubrovin wrote: > > I

Re: [mailop] RFC question on smtp replies...

Hello David. RFC 821 is outdated, use RFC 2821 as proposed or RFC 5321 as a draft for SMTP. Also, there is an RFC 3463, it adds extended status codes and you should probably read it. According to RFC, only code (and potentially extended status code) are intended for machine interpretation. The r

Re: [mailop] self-signed cert for inbound TLS

STARTTLS is opportunistic and doesn't protect against active Man-in-the-Middle. In case of TLS problems it falls back to plain text. To protect against passive Man-in-the-Middle, there is no actual difference between the self-signed certificate and certificate from recognized CA, so, except may b

Re: [mailop] SPF/DMARC and subdomains

DMARC prevents usage of your subdomains in the From: header. SPF doesn't protect it in anyway, it only checks SMTP envelope-from. 25.08.2017 17:11, Cameron Dixon via mailop пишет: > Hello! I have a random question about SPF/DMARC and subdomains.  > > openspf.org [1] recommen

Re: [mailop] SPF/DMARC and subdomains

-can-inherit-the-policy-of-its-organizational-domain-i-say-yes/ >> >> >> >> --  >> <https://www.splio.com> >> >> >> Benjamin >> >> 2017-08-30 23:09 GMT+08:00 Vladimir Dubrovin via mailop >> mailto:mailop@mailop.org>>: >&g

Re: [mailop] DMARC reports not received from Google

We've never seen any ruf from Google, only ruas. Are there are any additional limitations / requirements to get forensics? 20.09.2017 18:57, Brandon Long via mailop пишет: > I've pinged the team, thanks for the reports. > > Brandon > > On Sep 20, 2017 8:36 AM, "Ken O'Driscoll"

Re: [mailop] unique/shared public DKIM keys per domain?

I can say nothing about Google, but selectors can really have indirect impact on the reputation. We do not bind reputation directly to objects like domains, selectors, etc and use dynamic tuples instead (that is content of this tuple is flexible to better match specific mailing type), and in many

Re: [mailop] mail.ru google and DMARC

SPF record is OK, see https://tools.ietf.org/html/rfc7208#section-3.3 mail.ru publishes strict DMARC policy (reject) to prevent spoofing. DMARC requires alignment between SPF authenticated domain and domain from RFC5322.From You perform SRS, so message you send is SPF-authenticated by your domai

Re: [mailop] mail.ru google and DMARC

ARC doesn't solve the problem either, because ARC requires trust to be established between all signers in the chain and receiver of the mesage. ARC doesn't provide any means to establish this trust. In short: ARC will only work with the whitelist of known forwarders and it doesn't contain any mea

Re: [mailop] mail.ru google and DMARC

ild a trust framework.  It should > also be possible for operators to contract with third party vendors > who have the expertise and/or volume to do that.  We could also be > wrong, that's one of the reasons the current plan is to publish the > ARC RFC on the experimental track. &g

Re: [mailop] Anybody have a pointer to a clued qwet.net mail person?

Getting 2 replies means SMTP PIPELINING is used, and "DATA" is sent before reply to "RCPT TO". 451 is a reply for 'RCPT TO' to and 503 is a reply to DATA.  qwest.net announce PIPELINING in EHLO, so it's OK. In this case, 451 should be used. 451 is probably result of graylisting and receiver expect

Re: [mailop] Gmail forwarding blowback

Address space for IPv6 is so huge, that it's almost impossible to keep IPv6 reputation data, and sender authentication is usually required. for IPv6 host Under normal conditions, SPF and DKIM are used to authenticate sender, but if you forward messages without address rewrite, all forwarded messag

Re: [mailop] Password habits - was Re: Gmail forwarding blowback

The HUGE problem with OAuth is there is no common way to specify authentication links, so authentication must be manually configured for every mail service with OAuth support. We use IMAP/SMTP+Oauth to collect mail from Gmail/Yahoo/Hotmail/Outlook/Yandex and we prefer for everyone to use OAuth to

Re: [mailop] Office 365 - Emails marked as not passing fraud detection

I would also suspect RDNS. The problem here is ip-103-219-120-34.stcolumba.customer-wan.caznet.com.au looks like dynamic address and does not resolve back to IP: $ host 103.219.120.34 34.120.219.103.in-addr.arpa domain name pointer ip-103-219-120-34.stcolumba.customer-wan.caznet.com.au. $ host ip

Re: [mailop] Different From domain and Reply-To domain

You should never do it, having different e-mails in From: and Reply-To, including ones from different domains, is a common practice. E.g., mailing lists like this can change From or Reply-To, most probably the message you read right now has From and Reply-To from different domains. 07.12.2017 16:

Re: [mailop] Earthlink trouble with our PTR

Not only Earthlink cares, it's a standard procedure. This validation confirms your IP really belongs to the domain. This is standard validation for PTR everyone does, without this validation you can set PTR to arbitrary domain (e.g. example.com). Not everyone rejects messages based on this check,

Re: [mailop] Earthlink trouble with our PTR

? > > -Ryan > > On 12/13/2017 03:32 PM, Vladimir Dubrovin via mailop wrote: >> >> >> Not only Earthlink cares, it's a standard procedure. >> This validation confirms your IP really belongs to the domain. >> This is standard validation for PTR eve

[mailop] SPF recommendations (was: Re: Earthlink trouble with our PTR)

ary ? >> >> -Ryan >> >> On 12/13/2017 03:32 PM, Vladimir Dubrovin via mailop wrote: >>> >>> Not only Earthlink cares, it's a standard procedure. >>> This validation confirms your IP really belongs to the domain. >>> This is standard vali

Re: [mailop] Only Earthlink failing DKIM, any contacts here?

It's weird to block messages on DKIM verification, I see no reason to do so, but usually there is a reason why DKIM signature breaks. Most common issue is malformed message is being normalized prior to DKIM check. You should verify in first place: 1. There is no 8-bit characters in headers 2. Ther

Re: [mailop] Is BitBounce for real?

This idea behind Betbounce is neither stupid nor new, and it's actually funny, because current proof of work (PoW) algorithms, including one in bitcoin,  are based on "hashcash" algorithm, and hashcash was initially developed to combat SPAM.  See https://en.wikipedia.org/wiki/Hashcash so the servi

Re: [mailop] Gmail's dkim=neutral

26.01.2018 13:07, Benjamin BILLON пишет: > > Hi there! > >   > > I have a case where one sender's message has been abused, reused by > someone who just added a Subject: line (so now there's two), before > sending it. > > Apparently the final recipient was at Gmail (given the headers I had > access

Re: [mailop] Gmail's dkim=neutral

26.01.2018 17:37, Benjamin BILLON пишет: > > Thanks for those details, > >   > > My understanding is that SPF was primarily conceived against spoofing, > and not for reputation purposes. > > It doesn't mean that spammers can't have a proper SPF. It doesn't mean > that legitimate senders can't have

Re: [mailop] Email to rackspace.com bouncing?

Rackspace recently announced IP ranges changing, check IPs you are trying to send are matching to current Rackspace MXs 12.03.2018 20:25, Anne P. Mitchell Esq. пишет: > We just tried sending email to three different (known to be live a few weeks > ago) Rackspace addresses, and all 3 bounced as

Re: [mailop] facebookmail.com SPF violations by Microsoft IPs

Probably, somebody has set a redirection rule from his outlook account to mailbox on your server. If so, there is no problem except misconception valid mail can only arrive from SPF authenticated server. 17.03.2018 15:38, postmas...@akxnet.de пишет: > Hi! > > In my mail server logs, I notice for

Re: [mailop] facebookmail.com SPF violations by Microsoft IPs

SRS was never accepted as a standard. Some servers implement SRS and some do not. There is at least one good reason to avoid SRS: by rewriting sender you add your domain's SPF authentication to the messages you do not control, including spam. Content of forwarded messages may (negatively) affect y

Re: [mailop] Received header address information

According to RFC 2822, text in () represents comment (see section 3.2.3) and is used in the place where RFC2821 allows CFWS. CWFS is allowed to contain a comment (it's what differs FWS from CFWS). So, while this format is not optimal for automated parsing, it does not violate RFCs. 19.04.2018 0:

Re: [mailop] Received header address information

quot; (and thouse matches Extended-Domain) and parenthesized text matches CFWS. 22.04.2018 0:31, Steve Atkins пишет: > >> On Apr 21, 2018, at 10:27, Vladimir Dubrovin via mailop >> wrote: >> >> >> According to RFC 2822, text in () represents comment (see sectio

Re: [mailop] Migrating to new IPs?

Check PTR/FCrDNS/SPF/DKIM/DMARC for messages coming from new IPs, and start to warm up new IP range by moving some fraction of traffic to it. For < 10K mails/day I don't think you have something to worry about. You may have a problem if you are a mail forwarder, e.g. you manage a public mailing l

Re: [mailop] verizon.com Postmaster

There is no requirement in any standard for HELO name to have A record. It may e.g. have SPF TXT record. RFC 5321 says The domain name given in the EHLO command MUST be either a primary host name (a domain name that resolves to an address RR) or, if the host has no name, an add

Re: [mailop] Mailbox full impact on delvierability

There are 2 different things: 1. Sender base management. I think best strategy here is  - after the first delivery failure due to "mailbox full" put mailbox "on hold" on 24-48 hours (it's a normal situation, even active user may have mailbox overflown), If mailbox is online after this period the

Re: [mailop] Gmail change DMARC Policy?

DMARC works as expected, you have authentication for 94983.senders.tstes.net, 94983.returnpath.tstes.net, gmail.tstes.net but from is emaw...@gmail.com, so DMARC fails, because neither of authentications is aligned with gmail.com. In situation like this (message has unauthenticated From address

Re: [mailop] Reputation accrual on friendly from header

"From" domain is rarely used for reputation directly, usually authenticated domains (SPF that is envelope-from and DKIM domains) are used, but currently it's quite important for From domain to be authenticated regardless of DMARC, that is it must be aligned with at least one of SPF/DKIM domains, s

Re: [mailop] Certificate chain when encrypting SMTP

For opportunistic TLS, there is no difference between certificate signed by CA and self-signed certificate (or even unsigned), because cerificatate is usually not validated. Certificate validation is useless here, because opportunistic TLS falls back to cleartext anyway. For DANE, again there is

Re: [mailop] Certificate chain when encrypting SMTP

P.S. for client access (SMTP submission) validation is also important, whole chain must be provided for better compatibility. 13.09.2018 16:30, Vladimir Dubrovin пишет: > > For opportunistic TLS, there is no difference between certificate > signed by CA and self-signed certificate (or even unsign

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

06.11.2018 21:15, Michael Peddemors пишет: > Like any organization, when the volume of unwanted exceeds the volume > of wanted, you flag them... and let customers 'This is not junk' the > ones they want. It means having the rule with up to 50% of false negatives. If we use rules like this we have

Re: [mailop] freenet.de rejecting with 451 that should be a perm error (suspicious message)

I can't say for freenet.de, and I doubt somebody will explain his antispam tactics in details, but generally using 4xx like this is very common. 1. Graylist filter checks if you re-send the same message, because many spammers don't even try. 2. It may be result of ratelimiting, message above rate

Re: [mailop] SPF soft fail vs. hard fail

SPF (RFC 7208) explicitly allows recipient to block e-mail based on SPF policy in the case of the hard fail. In practice, blocking mail based on hard fail policy is rare, but not unusual. In short, there are 2 recommendations for you situation: 1. Consider implementing SRS (sender rewrite schem

Re: [mailop] Quick question on SPF...

Probably, this question is from misunderstanding on how DNS round-robin works. a:dispatch-us.ppe-hosted.com causes SPF to query A record for dispatch-us.ppe-hosted.com. Response for this query contains _all_ A records (not a random one, as you probably think). It means every IP from the list belo

Re: [mailop] MTA/Network Abuse lesson

SPF is not ignored by GMail, Outlook and others, SPF is used in a way it's supposed to be used in accordance to RFC 7208. Main SPF role is to determine if sender's domain and it's reputation may be used in delivery decision making. In the case of failed SPF, domain's reputation is not affected, be

Re: [mailop] 2 Return-Path headers?

According to current practices and standards, Return-Path header should never be added by sender. This line is usually added by MDA (Mail Delivery Agent) when the message is delivered to mailbox and is always a first line of delivered message, but older systems could add Return-Path during transfe

Re: [mailop] SPF: What happens if includes specify different 'all' settings?

Hello Benoit, "include" mechanism does not produce "fail" or "softfail", it only produces "match"/"non match" result, like any over mechanism (ip, a, mx, etc). That is, you can use "+include", "-include" or "~include" like with any mechanism, "include" means "+include". So, there is no difference

Re: [mailop] Yahoo Mail Servers having new issues?

We observe this behavior periodically and it seems the number of lost connections still grows. < *@yahoo.com >: delivery temporarily suspended: lost connection with mta5.am0.yahoodns.net[98.136.217.203] while sending RCPT TO We've contacted Yahoo support for multipe times and we've got a

Re: [mailop] Outgoing TLS

STARTTLS itself doesn't protect against active MitM attack, because attacker can strip STARTTLS from server's banner and according to standard, client should fall back to cleartext in this case. To protect against passive MitM, there is no need to validate certificate because self-signed certifica

Re: [mailop] Outgoing TLS

In the case of STARTTLS failure SMTP falls back to cleartext (unless DANE or SMTP STS is used to indicate STARTTLS is required). Encryption with invalid certificate in this case is better than no encryption. Jeffry Dwight пишет: > Thanks for all the replies. > > Is it even worth checking the cert

Re: [mailop] Spam Filtering Trick that could be easily adapted to Spam Assassin

These "concepts" are sometimes referred as "shingles", and example of shingles usage is e.g. in https://www.google.com/patents/US20140365585 Marc Perkel пишет: > This is a spam filtering trick I'm using but it's not SA, but could be > easily adapted to SA or other filtering systems. I thought I'd

Re: [mailop] signup form abuse

You definitely need anti-bot protection because currently you produce bounce SPAM and may be used for targeted SPAM / DDoS, especially if you reflect some user input (e.g. First name / last name). Currently, bots of this kind do not bother to emulate user behavior and checking user have visited fo

Re: [mailop] Reputable place to host my SMTP?

Also, there are problems with SPF record: Results - PermError SPF Permanent Error: Too many DNS lookups See https://tools.ietf.org/html/rfc7208#section-4.6.4 Renaud Allard via mailop пишет: > > > On 07/06/16 22:09, Robert Guthrie wrote: >> We've been having issues for months now, with google

Re: [mailop] Quick practical question on DMARC.

DKIM is a way to authenticate message by signing domain, it doesn't tell you which domain should sign this message and what should you do if the messages is not signed. DMARC does not replace DKIM, is uses DKIM and SPF as an authentication mechanisms. DMARC is a way to publish an authentication

Re: [mailop] Dealing with a DKIM replay attack and yahoo's use of DKIM domains for FBL reports

There are few ways to mitigate attacks: 1. Add timestamp (t=) to DKIM-Signature. It limits replay attacks in time. 2. Use per-user selectors with different keys (as it was advised) and remove DKIM records if replay attack is detected or simply switch to new selector if per-user keys are impossib

Re: [mailop] Dealing with a DKIM replay attack and yahoo's use of DKIM domains for FBL reports

Robert Mueller пишет: > >> 1. Add timestamp (t=) to DKIM-Signature. It limits replay attacks in >> time. > > Assuming the receiving side looks at it. But you probably mean the x= > tag anyway to set the expiry time, the RFC explicitly says though: > > INFORMATIVE NOTE: The "x=" tag is not intended

Re: [mailop] Gmail blocking due to "missing" PTR record

This PTR record fails the reverse check: >host 167.89.88.20 20.88.89.167.in-addr.arpa domain name pointer o1.webmaillist.flowerdeliveryexpress.com. >host o1.webmaillist.flowerdeliveryexpress.com Seth Charles via mailop пишет: > Hello, > We're running into a strange issue I'm wondering if an

Re: [mailop] Issues Receiving from MSN/Hotmail

May be, it's because you use self signed certificate for STARTTLS. I see no any reason for MSN/Hotmail to check certificate for STARTTLS though, and anyway it should fallback to unencrypted connection, unless you published DANE (RFC 7672). Dave Brockman пишет: > I'm assisting a client who is havi

Re: [mailop] hotmail.com bouncing DMARC p=none emails

It's probably due to -all in SPF kuspit.com descriptive text "v=spf1 ip4:200.53.152.189/32 ip4:200.53.152.185/32 ip4:200.53.152.182/32 include:icpbounce.com -all" BTW: DMARC (RFC 7489) recommends to use 'DMARC' as a keyword to indicate reject reason in in 550 message text. Justin Frechette пиш

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

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 dif

Re: [mailop] Spamcannibal?

25.11.2016 22:50, Al Iverson пишет: > Hi Otto, > > Long time no talk. Hope things are going well. > > The Spam Cannibal maintainer is a reasonable guy. He doesn't spread > his contact info far and wide, perhaps because he doesn't want to > argue with spammers. So, I would feel bad about sharing his

Re: [mailop] Issue with email parsing at YAHOO

It depends on Content-Type at least. If you e.g. have Content-Type different from text/plain or text/html you should not expect content to be shown inline. If you use multipart/related instead of multipart/mixed behavior is also unpredictable, and it's a common practice to show related part as an

Re: [mailop] Reg. Delivery issue at Gmail

> connection its taking more than 5 sec... Please find below samples for > the same.. According to this log, the problem is on your side: 2017-04-23 17:05:00 >>> 250 2.0.0 OK 1492947299 o80si8033594ito.126 - gsmtp 2017-04-23 *17:05:04* <<< QUIT You are waiting for 4 seconds before QUITE after

Re: [mailop] Reasons ISPs (Microsoft) ignore DMARC policy?

quick googling: https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/use-dmarc-to-validate-email#inbounddmarcfail How Office 365 handles inbound email that fails DMARC If the DMARC policy of the sending server is p=reject, EOP marks the message as spam instead of re

Re: [mailop] Reasons ISPs (Microsoft) ignore DMARC policy?

Any forwarding without RFC5322.From munging breaks SPF authentication for DMARC. With SRS message passes SPF but fails DMARC/SPF check because SPF domain after SRS is not aligned with RFC5322.From. DKIM is supposed to solve the problem of MTA-level forwarding. But, mailing lists also break DKIM,

Re: [mailop] FW: [dns-operations] weird queries for mx1.mx2.mx1.mx2...

 truckinsurancekentucky.com is unreachable, so it's hard to say, but it's more like some sort of CNAME loop. E.g. request to where domain is subdomain of  truckinsurancekentucky.com replies with CNAMEs to mx1. and mx2. 30.03.2020 14:43, Rose, Scott W. (Fed) via mailop пишет: > Forwarding this

Re: [mailop] outlook.de all emails from a specific sender flagged as spam, triggering false positive feedback loop - no remedy?

Benoît, I'm just curious - have you received _new_ FBLs for mailboxes of the students you have called to? 14.05.2020 12:33, Benoît Panizzon via mailop пишет: > Dear List > > A teacher is customer on our email platform and with covid-19 > homeschool, she is sending daily email to her class. > >

[mailop] Mail.ru new network range and TLSRPT support

1. Mail.ru starts using 45.84.128.0/23 for webmail traffic, please update your ratelimits / rule descriptions 2. We have recently implemented TLS reporting with MTA-STS supported, please let me know if you see any issues with it. -- Vladimir Dubrovin Technical advisor @ Mail.ru

Re: [mailop] Mail.ru new network range and TLSRPT support

HRB 7666 Geschäftsführer: Alexander Charles, Ralf Hartings, Thomas Ludwig, Jan Oetjen Member of United Internet -Ursprüngliche Nachricht- Von: mailop Im Auftrag von Vladimir Dubrovin via mailop Gesendet: Mittwoch, 17. November 2021 14:31 An: mailop@mailop.org Betreff: [mailop] Mai