Re: [mailop] Reason for being listed at Spamhaus CSS and XBL unclear
Sebastian Arcus via mailop wrote:- >> Michael's suggestion of checking for compromise of CPE (routers etc) is >> also well worth pursuing. > >I have though about that as well. The only possibility that I can come >up with is the Fritzbox VDSL modem/router sitting in front of the Linux >gateway/firewall. Try a packet capture between the Linux gateway/firewall and the Fritzbox, or (depending where any NAT is done) just inside the gateway/firewall. Then when re-listed you will either have the offending traffic or, if not, the issue is on the far side of your capture point. In saying this, there is some guessing about your network configuration. -- Best wishes, Matthew ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Reason for being listed at Spamhaus CSS and XBL unclear
Sebastian Arcus via mailop wrote:- >In that case I think I am back to square one. If an infected device >connecting to 587/465 to various servers on the internet, from our >network, to try and guess passwords/break into accounts wouldn't have >used the FQDN of our public IP as HELO - then that's not what is going >on. The Spamhaus info mentions the HELO being our public IP FQDN. The Spamhaus link (with your IP 51.155.244.89 you mentioned before in this thread) does show the EHLO matching the reverse DNS of the public IP. Reading it also implies that the issue is with port 25 rather than 587/465. You could try doing packet captures on your router (before NAT) for outgoing port 25 traffic, which should give a clue to the internal source. Don't overlook the possibility that the malware might be on the same machine as Exim. Michael's suggestion of checking for compromise of CPE (routers etc) is also well worth pursuing. -- Best wishes, Matthew ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] mimecast "antispoofing"
The "anti-spoofing" policies within Mimecast are configured on a customer by customer basis. These policies are a fairly blunt tool, and are set by default on new Mimecast accounts. They can apply to the "From:" header, the sender envelope address or both. The member should be able to take it up with their IT folks who can adjust the Mimecast policies accordingly. Such policies are known to cause trouble in these sorts of scenarios. Hope this helps... Best wishes, Matthew (NOT from Mimecast, but I have clients who use it) -- >From: Julian Bradfield via mailop >To: mailop@mailop.org >Cc: >Date: Tue, 5 Mar 2024 21:01:57 + (GMT) >Subject: [mailop] mimecast "antispoofing" >I just had a bounce, when a member of the list posted, from what is >presumably a mimecast served company, to one of my club lists. >The member's own copy of the list posting was bounced by his provider >with > > 550 Rejected by header based Anti-Spoofing policy: >[member's address redacted] - > https://community.mimecast.com/docs/DOC-1369#550 > [_gg8dmJZP_u-QdQxhMDwLg.uk114] > >I suppose that this means they don't accept a message "From:" an >address they serve - but the message was DKIM-signed by the company my >member sent from, so they should know it's not a spoof! (And my list >is DKIM-clean.) > >What should they be doing according to "best practice"? > >Julian. > >___ >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] 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
[mailop] Bounce Address Tag Validation (BATV) versus Spam Filtering
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
Re: [mailop] Best practice for mailing list servers
Ken O'Driscoll wrote:- >* Use different DKIM keypairs for each list Out of interest, why? Are there any known issues with using the same keypair across multiple lists, or indeed across multiple sending domains? -- Best wishes, Matthew ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Email System Testing Methodologies?
Slavko:- >D?a 13. júna 2022 11:19:08 UTC pouívate? Matthew Richardson via mailop > napísal: > >>One item to be aware of is that the outgoing servers (which return the >>messages) do DANE validation, and thus will not deliver to any servers with >>failed DANE. > >pleaee, is no DANE considered as failed DANE? (Only to be sure...) No (as Kurt observed), it will not send to servers which fail DANE but will send to servers without DANE. For anyone interested, the relevant Postfix setting is:- smtp_tls_security_level = dane Also, the inbound servers have TLSA records published. I have been wondering for a while whether a test server, running an address like p...@stamper.itconsult.co.uk, but with deliberately failing DANE would be useful for testing things. If it gives a reply, then the DANE is not being tested properly. -- Best wishes, Matthew ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Email System Testing Methodologies?
Jesse Hathaway:- >I am working on some architectural changes to our email systems at the >Wikimedia Foundation[1] and I am a bit befuddled as to the best way to >test changes to the current system. As you all are all aware email is a >distrubted system which encompases a wide variety of protocols. Ideally >I would like to know that our system behaves as expected with regards >to: mail routing, spam detection, and spam avoidance (SPF, DKIM, ARC). >Do folks have any suggestions on methods or systems to do this type of >whole system testing? Yours kindly, Jesse Hathaway > >[1]: https://wikitech.wikimedia.org/wiki/Email_System_Revamp Another gadget to test SPF/DKIM on outgoing messages is our p...@stamper.itconsult.co.uk. It replies with the headers it received, which will include our system's checks of the incoming SPF & DKIM. It will work (and report) if either or both fail. It does not (currently) do any DMARC checking. One item to be aware of is that the outgoing servers (which return the messages) do DANE validation, and thus will not deliver to any servers with failed DANE. -- Best wishes, Matthew ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Exchange 365 outbound connector being used as a relay
Alexander Huynh via mailop wrote:- >On 2022-01-29 09:15:02 +0000, Matthew Richardson via mailop wrote: >> You may wish to have some authentication between O365 and Exim. The MS >> document linked discusses how to do this with certificates. > >The certificate setup listed at that page did not provide settings for outbound >connector client certificates. Having looked harder at the document in your first link, and at setting up an outbound connector, you are indeed correct that there is no meaningful way to validate the specific connector to your Exim. I was (with apologies) mistaken in suggesting this. This does seem rather sub-optimal! Furthermore, for a connector going INTO O365, one can require a particular name in the certificate. -- Best wishes, Matthew ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Exchange 365 outbound connector being used as a relay
Alexander Huynh via mailop wrote:- >Meaning that domains `outlook.com` and `mail.alokind.com` have managed to use >Exchange >365 infrastructure to try and route email through my connector. As a thought (probably wrong) could this be caused by your O365 users forwarding INCOMING email to them FROM outlook.com and/or mail.alokind.com to external addresses? >My questions are: > > * Is this expected? Whilst not being an expert, probably not. > * Are there any safeguards in place from preventing one tenant from using > another >tenant's connectors? It is not certain that this is what is occurring. For example, your setup would not preclude other tenants pointing their outgoing email to your Exim (not that this would be sensible for them). > * (!) `outlook.com` was somehow routed to my connector, how did that happen? > * What are the suggested methods for preventing other tenants from using > connectors >with IP allowlists (i.e. are domain allowlists the way to go, are there > other >methods)? You may wish to have some authentication between O365 and Exim. The MS document linked discusses how to do this with certificates. If authentication is implemented and messages flow, one knows that the use of the connector is intentional from the O365 end. -- Best wishes, Matthew ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Spamcop
On Sun, 31 Jan 2021 09:01:39 -0800, Don Owens via mailop wrote:- >We have the domain back now, but we have to wait for propagation delays. If >you query the name servers they Arne mentioned, that should give you the right >IPs. > >Sorry for the trouble, folks. Now I have to go see who needs flogging. Without wishing to state the obvious, the use of auto-renew would assist. Also, having delegation check monitoring (with prompt alerting) makes a very good additional safety net. Taken together, they would mitigate the future need for flogging! :-) Best wishes, Matthew ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] DNS issues for CloudFilter?
As far as I am aware, the SOA SERIAL on authoratitive servers is not involved in any resolution by resolvers; in short, resolvers don't make use of it. The only thing resolvers do use from the SOA is the TTL for negative caching. Best wishes, Matthew -- >From: Bill Cole via mailop >To: "Matthew Richardson via mailop" >Cc: >Date: Tue, 12 Jan 2021 08:24:36 -0500 >Subject: Re: [mailop] DNS issues for CloudFilter? >On 12 Jan 2021, at 3:02, Matthew Richardson via mailop wrote: > >> That NS is provided by AWS Route53. My experience is that they have >> some >> sort of internal propriatory propagation of updates which does not use >> the >> serial number. Looking at another zone, I also think that they leave >> the >> serial number at 1 all the time. > >That seems likely to cause (transient) problems for resolvers that >expect authoritative servers to behave in standard ways. > > > >> Best wishes, >> Matthew >> -- >>> From: Bill Cole via mailop >>> To: "Frank Bulk via mailop" >>> Cc: >>> Date: Mon, 11 Jan 2021 15:07:29 -0500 >>> Subject: Re: [mailop] DNS issues for CloudFilter? >> >>> On 11 Jan 2021, at 13:33, Frank Bulk via mailop wrote: >>> >>>> Looks like it's good now. >>> >>> Yes. I think I see a likely source of the problem: >>> >>> $ dig mx.a.cloudfilter.net soa >>> [...] >>> ;; ANSWER SECTION: >>> mx.a.cloudfilter.net. 900 IN SOA ns-1804.awsdns-33.co.uk. >>> awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400 >>> >>> It seems likely that there was at some point a higher zone serial >>> number. >> >> ___ >> 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] DNS issues for CloudFilter?
That NS is provided by AWS Route53. My experience is that they have some sort of internal propriatory propagation of updates which does not use the serial number. Looking at another zone, I also think that they leave the serial number at 1 all the time. Best wishes, Matthew -- >From: Bill Cole via mailop >To: "Frank Bulk via mailop" >Cc: >Date: Mon, 11 Jan 2021 15:07:29 -0500 >Subject: Re: [mailop] DNS issues for CloudFilter? >On 11 Jan 2021, at 13:33, Frank Bulk via mailop wrote: > >> Looks like it's good now. > >Yes. I think I see a likely source of the problem: > >$ dig mx.a.cloudfilter.net soa >[...] >;; ANSWER SECTION: >mx.a.cloudfilter.net. 900 IN SOA ns-1804.awsdns-33.co.uk. >awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400 > >It seems likely that there was at some point a higher zone serial >number. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
