Re: [mailop] Thread-Index header too long
On 10/18/22 8:28 AM, WIlliam Fisher via mailop wrote: I'm pretty sure DKIM wouldn't include the non-standard threading headers. /Default/ DKIM configurations probably don't include the threading header(s) (References & In-Reply-To). But it's certainly possible that they are included. That being said, I see that both References: and In-Reply-To: are included in the DKIM-Signature: of the message that I'm replying to. I've re-wrapped it to make it easier to read. DKIM-Signature: v=1; a=rsa-sha256; bh=2HJH0z8OPqiZSksYlT5t9QkCZyw3VikRfFdD5Blq7oU=; c=relaxed/relaxed; d=earthlink.net; h=from: reply-to: subject: date: to: cc: resent-date: resent-from: resent-to: resent-cc: in-reply-to: references: list-id: list-help: list-unsubscribe: list-subscribe: list-post: list-owner: list-archive; q=dns/txt; s=dk12062016; t=1666103332;x=1666708132; b=QSe+qudK+EvZiTVCfIIyY1ZZVBmtwmw1sEI1OSB0BRPEpgwr/IM41U43QjJNOOmku5a328ciBXHw1g3ncgL69gfnBrkXSAgcxavl6uQL7J2/3AbNe5w0Kj29w7mZpSPa/8YNMp8KkTaGCrN54EUWys2Zglz0a1EocvpRg3JjeJ99l66dKGxj0EJN7G/akyw26EXdjbbTy7OrNvVQn5z1vaFtLFZtsgmAAJRTsHRspoyaSlnAom7R5vBIUrd5ILqHKcrDpWV9KjsYmLl+pRv3dU57RaEt8VGrATwkfAbyJmTnF3uKNuM03K73NQ9ewWjIgkDhep3RRLesdgjPdrb0iA== Including the resent-* headers is interesting to me, seeing as how they aren't included in the message. I don't know if this was an intentional over-sign or over zealous configuration. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Thread-Index header too long
On Mon, Oct 17, 2022 at 10:43 PM Grant Taylor via mailop wrote: > On 10/17/22 10:17 PM, Brandon Long via mailop wrote: > > Right, but you can't stick a non-compliant message into a DSN > > directly and have that be a compliant message... so you either make > > the non-compliant message compliant when you stick it into the DSN, > > or you figure that a sender who sends a non-compliant message can > > handle a non-compliant response. > > Are you talking about the 3rd and optional part of RFC standard Delivery > Status Notifications, a.k.a. Bounces? -- I'm going to assume yes until > corrected. > Yes. First, the message that caused the ""bounce is optional. > Note that if Gmail can't find the message-id of the bounce message and correlate that to a message in the receiver's mailbox, it will likely mark the bounce message as spam. We would highly recommend folks include the original message or headers in their bounce messages, and just about everyone does. Second, why would you send the entire message (message/rfc822) in the > DSN? There's too good a chance that you inadvertently send (as in > originate a permutation of) -- at best -- questionable content. I'd > think that you would want to only send the headers (text/rfc822-headers). > Like I said, if the bounce receiver didn't send it, we'll mark it as spam anyways. And bounce messages are already hard enough for customers to understand, so including the original helps them understand what bounced. Anyways, I think we do fall back to headers-only in some cases like very large messages... and sometimes to message/global depending. Another use case, where the DKIM thing is useful, is for ARF reporting (rfc5965), and there the third part is required. Or are you talking about a completely new message that is a stand in for > an RFC standard DSN but looks completely different? > > Either way, I see no reason to worry about altering the message. Send a > sub-set of it (which is often sufficient to identify the original > message) or don't send it. Either way, there's not enough to worry with > DKIM validation of what was received by the mail system generating the DSN. > > > And while this particular case of re-wrapping lines is fairly easy > > to fixup when generating the DSN, > > }:-) > > > other cases like embedded non-utf8 8bit characters are more > > complicated... just auto-detect the language, convert to utf8 and > > embed in a message/global, I'm sure their system will know what to > > do with that ;) > > I would snarkily reply add the original message as a message/rfc822 > attachment that is base64 encoded. Except Google has a propensity of > disliking message/rfc822. -- For the longest time Gmail didn't support > it. > We used to do this (or rather, just let the regular cte encoding logic choose, which included using quoted-printable for too long lines)... but it turns out that while a bunch of parsers support decoding it even though it's against the rfc, many do not. As for supporting message/rfc822 attachments, we had some issues where a very loud subset of early customers preferred it being a download link instead of displayed inline, and it took some time to convince PM to override that... I think it still may listen to the Content-Disposition header whether to show inline or not. Brandon ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] Tales from the Trenches, Observed activity by SpamAuditors
Strange last couple of days.. with renewed activity of old techniques. Keeping it to point form this time: * SendGrid still having problems, increased detection again (Love this spam, From: Department of Defence ) * IPXO got a new /16 in September, and already being leased to spammers Organization: EpicUp Holdings Inc (EH-1516) Organization: IPXO LLC (IL-845) 140.99.0.0/16 * LeaseWeb is still a pain in the *ss * LayerHost still loves letting snow shoe spammers thrive * servconfig.com. seems to have had a problem with compromised accounts all week.. * MailJet Gesty spam.. From: =?UTF-8?q?GestyFor=2C_formaci=C3=B3n_para_una_inmensa_minor=C3=ADa?= * OVH (vps-a869e703.vps.ovh.net) large ranges * Contabo Phishing operations * High Number of SMTP Auth Attacks from someone forging or relaying static.182.238.9.176.clients.your-server.de * Serverion Attacks continue unabated, email and other attacks * Google still letting out too much Nigerian Spam, and Fake Funds.. * Google/Amazon/Azure source attacks continue * Far too many compromised accounts from Latin Amaerican governments * Strange attacks from China Unicom IP space, moves from /22 to /22 * LogicWeb attackers, trying to pretend to be * DediPath whole ranges being used by the same spam actor * Old favourites from Europe, GigaNet, Pitline et al.. still keep showing up on the radar. -- "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://list.mailop.org/listinfo/mailop
Re: [mailop] Bounce Address Tag Validation (BATV) versus Spam Filtering
Thanks to Al for his (as usual!) useful thoughts. I was cheekily wondering whether the original authors of the BATV Internet Draft, John Levine, Dave Crocker and Tony Finch (I don't think Tony is subscribed to mailop), might have any views on the probity of its use in today's times. This question is particularly in the context of using BATV for normal (ie person to person, non bulk) outgoing messages. Best wishes, Matthew -- >From: Al Iverson via mailop >To: mailop@mailop.org >Cc: >Date: Thu, 13 Oct 2022 10:07:24 -0500 >Subject: Re: [mailop] Bounce Address Tag Validation (BATV) versus Spam >Filtering >I don't know that non-matching return path/from are something you >truly have to solve for. At the domain level, it's addressed by DMARC. >At the exact email address level, any mailing list software, ESP or >CRM tool that uses VERP to help with bounce processing is going to >have a mismatched return-path/envelope sender. >IMHO, hasn't really been a good spam sign for a good long time. > >Cheers, >Al > >On Thu, Oct 13, 2022 at 9:22 AM Matthew Richardson via mailop > wrote: >> >> I have an issue with email from one domain being repeatedly mis-classified >> as spam by assorted receivers, including Messagelabs. >> >> Looking at their outgoing email, I notice that it uses BATV, the Internet >> Draft https://datatracker.ietf.org/doc/html/draft-levine-smtp-batv having >> been written by folks who frequent these part. >> >> Whereas the "From:" header would read:- >> From: First Last >> >> the envelope address would read:- >> btv1==278381d6d8b==first.l...@example.com >> >> My understanding is that this BATVing is being undertaken by a Barracuda >> appliance through which outgoing email is routed. >> >> Would folks anticipate that doing this would somehow make outgoing email >> look more spammy than with a matching envelope address. >> >> -- >> Best wishes, >> Matthew >> ___ >> 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] Thread-Index header too long
I've seen these headers as well. They were coming out of one particular "groups" mail system, likely added as an artifact of that process. The super long headers can also cause some clients to just not display the messages. I'm pretty sure DKIM wouldn't include the non-standard threading headers. On 10/18/22 2:46 AM, Heiko Schlittermann via mailop wrote: Grant, thanks for your fast response. Grant Taylor via mailop (Di 18 Okt 2022 00:41:24 CEST): I would (try to) configure my MTA to re-wrap the logical line to conform to … Modification of existing headers isn't something I would recommend. Except for headers that aren't protected by DKIM. I would naively assume that Exim (or any contemporary MTA) could deal with logical (unfolded) header lines of largely any length. Exim *can* process these overlong headers. But its default config rejects the transport of messages containing them. (Probably the default config even rejects such messages, I'd need to check.) The *intention* of my question was more like "what do you do with such messages", as I believe that I'm not the only one seeing them. OTOH *iff* I'm the only one, than the issue might be scoped to a specific sending system. Although the reporter told me, that they're lots of such messages. If it wasn't for the messages purportedly being from MS Outlook 16, I'd wonder if this was some sort of attack. The message itself wasn't suspicious and had a trustworthy sender. (But I'm not sure if it was really an Outlook generated message, or some sort of script impersonating as Outlook.) ___ 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] Apple contact for strange email
These hosts deliver newsletters and marketing content that Apple sends to email addresses that are Apple IDs. I will let the team in question know to fix their PTR for these hosts – thanks for the heads up --srs From: mailop on behalf of Alexander Huynh via mailop Date: Tuesday, 18 October 2022 at 11:54 AM To: mailop@mailop.org Subject: [mailop] Apple contact for strange email Hello, I've been seeing a few mail connection attempts from Apple's IP space, which I've been rejecting due to mismatched A / and PTR records (see sample log at the end, times UTC). Is there anyone at Apple who can contact me off list? Thanks, -- Alex Oct 10 11:39:35 H=[17.240.49.64]:18357 rejected connection in "connect" ACL: host lookup failed (17.240.49.64 does not match any IP address for mr52p01nt-msbadger008105.ise.apple.com) Oct 11 11:33:50 H=[17.240.49.39]:35629 rejected connection in "connect" ACL: host lookup failed (17.240.49.39 does not match any IP address for mr45p01nt-msbadger005101.ise.apple.com) Oct 12 11:42:46 H=[17.240.49.58]:55433 rejected connection in "connect" ACL: host lookup failed (17.240.49.58 does not match any IP address for mr52p01nt-msbadger007106.ise.apple.com) Oct 13 11:27:15 H=[17.240.6.32]:25397 rejected connection in "connect" ACL: host lookup failed (17.240.6.32 does not match any IP address for st57p01nt-msbadger004101.ise.apple.com) Oct 15 12:35:44 H=[17.240.49.48]:37100 rejected connection in "connect" ACL: host lookup failed (17.240.49.48 does not match any IP address for mr52p01nt-msbadger006103.ise.apple.com) Oct 17 11:36:12 H=[17.240.49.33]:12835 rejected connection in "connect" ACL: host lookup failed (17.240.49.33 does not match any IP address for mr45p01nt-msbadger004102.ise.apple.com) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
