Re: [mailop] Best rate limiting response?
Luis E. Muñoz via mailop wrote: > > I did not clarify that this application is actually for a submission server to > be used by end users with run-of-the-mill MUAs. The approach we take at Cambridge University (with about 30,000 users) is to accept and hold messages when a sender is over their rate limit. The postmasters can then manually review and either release the messages, or lock down the account if it turns out to be compromised. We have the advantage that most of our legitimate high-volume mail comes from on-site clients, whereas roaming users tend to have relatively light usage, so we can have a fairly simple two-level policy. For MTA clients we 450, so that the departmental postmaster can see the mess themselves. This has a reasonable balance between the amount of manual work, the amount of cleverness in the rate limiter, and the amount of disruption to users and consequent hand-holding. Tony. -- f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode Lundy, Fastnet, Irish Sea: South or southwest 4 or 5 increasing 6 or 7, veering northwest 4 or 5 later in Fastnet. Slight or moderate becoming moderate or rough. Fair then occasional rain. Good, occasionally poor.___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Storing 821 envelope recipients in an 822.Header?
John Levine wrote: > > Oh, and some MTAs put them in Delivered-To: lines at the top of the > message, after the Return-Path:. Or Envelope-To: http://www.exim.org/exim-html-current/doc/html/spec_html/ch-message_processing.html#SECID225 Tony. -- f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode Humber, Thames, Dover, Wight, Portland, Plymouth: South or southwest 5 to 7, decreasing 4 at times. Slight or moderate, occasionally rough in Portland and Plymouth. Rain, fog patches in Plymouth. Moderate or poor, occasionally very poor in Plymouth. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] [SDLU List] Spam Filtering Trick that could be easily adapted to Spam Assassin
Marc Perkel wrote: > > Rather that just scan for regex strings it's useful to have a way to tell what > things the message is talking about and reduce those to a single token that > represents a concept. Then the concepts can be combined to produce rules or > fed into Bayes for automatic scoring. Check out SpamAssasin's meta rules. meta LOTTO_AGENT __LOTTO_AGENT && !__HAS_IN_REPLY_TO && !__THREADED && !__TO_YOUR_ORG && !__DKIM_EXISTS && !__TRAVEL_ITINERARY && !__AUTO_ACCIDENT Tony. -- f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode South Biscay, South Fitzroy: Northwesterly 4 or 5, becoming variable 3 or 4. Slight or moderate. Mainly fair. Moderate or good. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Cisco PIX Mailguard Oddity
Dave Warren wrote: > > They're broken by design and not fit for purpose. Among their many flaws, they > don't even make it to RFC821 3.1, the MAIL command, which is described as the > following: > > MAIL FROM: > > Instead, when they receive a "M" in a packet alone, they interpret it as an > invalid command and don't bother to parse the rest of the command. However, if > you deliver the whole command in one TCP packet, they will accept it; This is > patently stupid. > > Although TCP won't generally break up such a short string into multiple > packets there's actually nothing wrong with doing so and there's no > requirement in RFC 821 to send each command in a single packet. I have actually seen this happen in the real world, though it affected the RCPT comand instead of MAIL. The server offered PIPELINING and the PIX allowed it through, but if the pipelined RCPT commands happened to span a packet boundary the PIX destroyed the command, and thereby wrecked the transaction. http://fanf.livejournal.com/102206.html If you have a PIX or ASA, turn off all its protocol fuxup options. Tony. -- f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode Sole, Lundy, Fastnet, Irish Sea: North or northeast 4 or 5, occasionally 6 later. Rough becoming moderate in Sole, otherwise slight or moderate. Fair then thundery showers. Good, occasionally poor. ___ 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 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. Tony. -- f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode Trafalgar: Cyclonic becoming west or northwest, 4 or 5. Moderate, occasionally rough in north. Thundery showers. Moderate or good. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] DNS Errors for Microsoft Hostnames
Michael Wise wrote: > > So is the FORMERR ... just the resolver noting that EDNS is not supported? > > If so, I'm uncertain of the issue. There has been some discussion of this problem on the bind-users list, see https://lists.isc.org/pipermail/bind-users/2016-May/thread.html The problems seem to be: (1) Very short TTL on the NS records, which means that most attempts to resolve the names have to go through iterative name server discovery. (2) Only two NS records, but each server has a large number of IP addresses, and the sets of IP addresses overlap. (3) Lack of EDNS support means more work has to be done by a resolver each time the TTL expires. The way to fix this would be to increase the stability of the name server records - the NS records and associated address records. Give them decently long TTLs, have a few more NS records, with few non-overlapping IP addresses each. Add support for EDNS to your server - you don't need to support any special EDNS features (no need for large packets), just handle OPT records, so that resolvers don't have to do error recovery. Tony. -- f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode Irish Sea: South 4 or 5 becoming variable 3 or 4. Slight or moderate. Occasional drizzle, fog patches in north. Moderate or good, occasionally very poor in north. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] "Spammer TLDs" and IP addresses without a reverse?
Renaud Allard via mailop wrote: > On 04/19/2016 09:15 AM, Michelle Sullivan wrote: > > > > As well... ;-) (and for those that don't get it... the host issued 'HELO > > [65.55.234.213]' or 'EHLO [65.55.234.213]' .. perfectly legal but > > something malware and bots do as well.. > > While HELOing like this that might be perfectly "legal", this is > something which is probably going to be blocked as well by many/most > servers. I tried blocking HELO domain literals briefly in 2009 but the false positive rate was way too high. On the other hand, ^[0-9.-]+$ has been an effective and safe reason to block for many years. Tony. -- f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode Humber, Thames: Northwest, veering north or northeast, 4 or 5. Slight or moderate. Fair. Good. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Gmail Blacklisting
Thomas Wilhelm wrote: > > Does anybody have a hint for us, how to fix this problem? To send mail to Google over v6 you have to have SPF, DKIM, reverse DNS, everything set up to the best anti-spam standards. Tony. -- f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode Southeast Iceland: Northeasterly 5 or 6 becoming variable 3 or 4, then cyclonic 5 to 7. Moderate or rough, becoming slight or moderate for a time. Showers. Good. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] proper NULL MX behaviour for MTAs?
Franck Martin via mailop wrote: > > This could be true but then RFC7505 is recent, so I'm not sure that proper > MTAs are yet properly behaving. I wonder what sendmail, postfix, exim > really do? Exim has treated null MXs as invalid since 2004. https://www.ietf.org/mail-archive/web/apps-discuss/current/msg11051.html Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty, Forth: Southwest 5 to 7, backing south 6 to gale 8, occasionally severe gale 9 later. Slight or moderate, becoming rough or very rough later, occasionally high later in Forties. Rain. Moderate or poor. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] proper NULL MX behaviour for MTAs?
Suresh Ramasubramanian wrote: > A domain with a null mx may well originate email If they try to do that they will be sad. A lot of MTAs will reject email with a MAIL FROM using a domain that is invalid according to the DNS, and a null MX counts as invalid for this purpose. Tony. -- f.anthony.n.finchhttp://dotat.at/ Biscay, Southeast Fitzroy: Northerly backing southwesterly 5 to 7. Moderate or rough. Fair. Good. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] IBM SPF vs smtp.notes.na.collabserv.com
David Hofstee wrote: > If he knows that no forwarded mail should be sent via his mailserver, > spf should be fine, right? No, a sender with an SPF -all record needs to be certain that none of their users ever send mail to an address which forwards elsewhere. Of course it's unreasonable to expect non-technical senders to know the implementation details of recipient addresses... Tony. -- f.anthony.n.finchhttp://dotat.at/ Fitzroy, Sole: Westerly or southwesterly 6 to gale 8, perhaps severe gale 9 later in southeast Fitzroy. Very rough or high. Rain or showers. Good, occasionally poor. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Delivery to gmail via IPv6
David Hofstee wrote: > Ian Eiloart wrote: > > > > ... I prefer to call that a rejection rather than a bounce. ... > > https://xkcd.com/927/ This isn't competing standards, this is a fundamental feature of one standard. Ian is prefering to use exactly the same terminology as RFC 5321 section 6.2: If they cannot be delivered, and cannot be rejected by the SMTP server during the SMTP transaction, they should be "bounced" (returned with non-delivery notification messages) as described above. Tony. -- f.anthony.n.finchhttp://dotat.at/ South Utsire, Forties, Cromarty, Forth, Tyne, Dogger: Southerly or southwesterly veering westerly for a time, 5 to 7, occasionally gale 8. Moderate or rough. Rain or showers. Good, occasionally moderate. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Delivery to gmail via IPv6
Brandon Long wrote: > > I won't claim our failure mode here is correct for all cases, but the flip > side is, this is what you get with dnssec by design. By design the DNS distinguishes between nonexistent (i.e. NXDOMAIN or NODATA) and failure (SERVFAIL). If there is a security error DNSSEC gives you SERVFAIL. Mail systems traditionally treat DNS SERVFAIL as a temporary error, and only reject outright if they get NXDOMAIN or NODATA. So you can't blame DNSSEC for Gmail's choice to reject outright when it gets a SERVFAIL on a reverse DNS lookup. If spammers are playing silly buggers then a 4yz response should be just as effective as a 5yz response, and there is less risk of harming the robustness of legitimate senders. Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty, Forth: Southeast 5 to 7, veering southerly 6 to gale 8 later. Moderate or rough, occasionally very rough later. Occasional rain. Good, occasionally poor. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Delivery to gmail via IPv6
Franck Martin wrote: > It depends if it is at connection time, or after the RFC5321.MailFrom where > the SPF can be evaluated. If there is no valid rDNS and no SPF, rejecting > after SPF evaluation may not be a bad solution, If there is a DNSSEC failure you can't tell whether or not there is any rDNS. Failure to answer is not the same as an answer that says it is nonexistent. Tony. -- f.anthony.n.finchhttp://dotat.at/ Sole, Lundy, Fastnet: Southwest 6 to gale 8, occasionally severe gale 9 later. Rough or very rough, occasionally high later. Occasional rain. Good, occasionally moderate. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Delivery to gmail via IPv6
Franck Martin wrote: > http://dnsviz.net/d/5.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.4.7.2.0.0.1.0.0.0.0.0.1.5.0.4.2.ip6.arpa/dnssec/ Gmail should treat that as a temporary error not a permanent one. Tony. -- f.anthony.n.finchhttp://dotat.at/ Biscay: Southwesterly 5 or 6 in northwest, otherwise, northerly 4 or 5, becoming variable 3 or 4. Moderate or rough, occasionally very rough later in northwest. Mainly fair. Good. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Canonicalization
SM wrote: > At 13:22 16-10-2015, Luke M wrote: > > > > I was wondering if anyone would share their thoughts on RFC 1123 section > > 5.2.2. It states: > > > > The domain names that a Sender-SMTP sends in MAIL and RCPT > > commands MUST have been "canonicalized," i.e., they must be > > fully-qualified principal names or domain literals, not > > nicknames or domain abbreviations. A canonicalized name either > > identifies a host directly or is an MX name; it cannot be a CNAME. > > > > Does anyone know the reasoning behind this guideline? It seems like it is > > widely ignored. > > That section of RFC 1123 is no longer used. We-e-e-ll it isn't as simple as that. That requirement was removed when RFC 821 was revised by the IETF DRUMS working group in the late 1990s. However, Sendmail still implements this obsolete requirement unless you use FEATURE(`nocanonify'), and qmail also implements it. http://fanf.livejournal.com/10.html > The benefit of following the guideline is that you don't have to worry > about edge cases. The "benefit" of following the guideline is that people unrelated to you can put a CNAME in their DNS pointing at your mail domain, and people using qmail and sendmail will be able to mail you under this alias without any co-operation from you. Tony. -- f.anthony.n.finchhttp://dotat.at/ Fisher, German Bight, Humber: North 3 or 4, backing southwest 4 or 5 later. Smooth or slight. Occasional rain in Humber. Moderate or good. ___ mailop mailing list mailop@mailop.org http://chilli.nosignal.org/mailman/listinfo/mailop
Re: [mailop] Autoresponse spam - a growing phenomena
Gil Bahat wrote: > additionally, if all providers were to respect the > non-standard-but-should-be x-auto-response-suppress , it would do well to > stop this from hitting prudent transactional senders. They ought to implement RFC 3834. > funny thing is, this is a microsoft-specific (well, outlook-specific) > standard and yet not supported by office online or outlook.com. How utterly crap. Tony. -- f.anthony.n.finchhttp://dotat.at/ Tyne, Dogger: South veering west or northwest 5 or 6. Moderate or rough, becoming slight or moderate. Rain then fair. Poor becoming good. ___ mailop mailing list mailop@mailop.org http://chilli.nosignal.org/mailman/listinfo/mailop
