Re: [mailop] Application for rsync access to CBL

[TR Shaw]

Also through http://securityzones.net/

> On Dec 16, 2015, at 1:24 PM, Daniele Duca  wrote:
> 
> Hi Anthony,
> 
> we do have rsync access to Spamhaus feeds, but we obtained it through one of 
> their resellers, Spamteq, https://www.spamhaustech.com/ 
>  (probably there are also others, I don't know)
> 
> Once registered you require the trial and they follow up pretty quickly
> 
> Hope it helps
> 
> Regards,
> Daniele Duca
> 
> On 16/12/15 18:09, Rodgers, Anthony (DTMB) wrote:
>> Hi there,
>>  
>> We have made an application to Spamhaus for access to rsync the CBL, and 
>> followed up with email to 'c...@abuseat.org ' as 
>> recommended in the directions, but have not heard back in days.
>>  
>> Does anyone know if rsync access to the CBL is still a thing? Has anyone 
>> been recently successful in obtaining it?
>>  
>> --
>> Anthony Rodgers
>> Security Analyst
>> Michigan Security Operations Center (MiSOC)
>> DTMB, Michigan Cyber Security
>>  
>> 
>> 
>> ___
>> 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] Application for rsync access to CBL

[Rodgers, Anthony (DTMB)]

Hi there,

We have made an application to Spamhaus for access to rsync the CBL, and 
followed up with email to 'c...@abuseat.org' as recommended in the directions, 
but have not heard back in days.

Does anyone know if rsync access to the CBL is still a thing? Has anyone been 
recently successful in obtaining it?

--
Anthony Rodgers
Security Analyst
Michigan Security Operations Center (MiSOC)
DTMB, Michigan Cyber Security

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Application for rsync access to CBL

[Daniele Duca]

Hi Anthony,

we do have rsync access to Spamhaus feeds, but we obtained it through 
one of their resellers, Spamteq, https://www.spamhaustech.com/ (probably 
there are also others, I don't know)


Once registered you require the trial and they follow up pretty quickly

Hope it helps

Regards,
Daniele Duca

On 16/12/15 18:09, Rodgers, Anthony (DTMB) wrote:


Hi there,

We have made an application to Spamhaus for access to rsync the CBL, 
and followed up with email to 'c...@abuseat.org' as recommended in the 
directions, but have not heard back in days.


Does anyone know if rsync access to the CBL is still a thing? Has 
anyone been recently successful in obtaining it?


--

Anthony Rodgers

Security Analyst

Michigan Security Operations Center (MiSOC)

DTMB, Michigan Cyber Security



___
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] NDRs and DSNs was: Re: Delivery to gmail via IPv6

[Karen Balle]

Since there's been a lot of drift on this topic and I'm not talking about
IPv6, DNSSEC, or delivery to Gmail

For NDRs and DSNs to be truly useful to an ESP, we tend to break them down
into more buckets than two.

Hard bounce/invalid (do not retry, generally a 5xx)
Soft bounce (temporary and related to a specific email address, generally a
4xx, try again later during the current send, Yahoo uses 4xx where we would
expect a 5xx such as with some of the traffic shaping deferrals)
Technical (DNS failures and the like, try again later, generally 5xx but
depends on the reason)
Spam or block (stop for this send, try this recipient on future sends, mix
of 5xx and 4xx)
Unknown (parser doesn't have an appropriate string, manual review and
update of systems required)

The primary challenge from a technical perspective is making sure that any
changes in friendly language in an NDR or DSN is updated on the bounce
parser.  We do tend to MOSTLY ignore 5xx and 4xx, but that is more a
function of how those are used by mailbox providers.  The desired end
result is that we send all email in a manner that is acceptable to each
mailbox provider based on their (technical and personal) feedback and
desired rate limits.  Extended codes are useful, when you know how a
provider applies them, but again, there is such variation in the how codes
are applied and when that it's all but impossible for someone not steeped
in the intricacies of RFCs to interpret them properly.

Not all customers have access to people who spend a lot of time going over
bounces and making them actionable.  A lot of our job as an ESP is taking
the technical and making it understandable to someone who doesn't have the
training and background on RFCs and "proper" technical jargon.  I've spent
the last 18 years or so going over NDRs and DSNs and some still throw me.
Filters are also increasingly more complex and we see the same bounce used
for multiple purposes, so cross-referencing which bounces happen where is
becoming more important to understanding the root issue for a customer.



Cheers,
Karen

On Fri, Dec 11, 2015 at 9:06 AM, Ian Eiloart  wrote:

> I wonder why they don’t use the terminology from the RFCs: "reject",
> "defer", "non-delivery notification", "delay notification"?
>
> As it is, when you say "Hardbounce", I don’t know whether you’re referring
> to an SMTP 5yz reply (a rejection) by the receiving MTA or an rfc 3461
> "failed" DSN sent to the sender to alert them to the problem.
>
> Similarly, I don’t know whether "softbounces" means an rfc5321 temporary
> failure reply , or an rfc 3461 "delayed" DSN. Neither of which mean quite
> what you said, since the intention is that the sending MTA will retry for a
> period. The sending MTA can’t use other means. If the original sender tries
> again, then the recipient will get duplicate messages when the fault is
> resolved.
>
> If the ESP is good, the the sender will have access to a support team, so
> all faults should be actionable.
>
>
> > On 11 Dec 2015, at 11:59, David Hofstee  wrote:
> >
> > That’s why, in ESP parlance, there are two sorts of bounces, to keep it
> simple:
> > -  Hardbounces: The recipient address does not work. Contact
> through other means.
> > -  Softbounces: This email did not arrive. Try again later or
> contact through other means. If this keeps happening  the address
> effectively does not work.
> >
> > What else is there to do? The sender might be curious to what the reason
> is (if the bounce is even telling you that) but it does not change the
> outcome or the call to action. The only things that are actionable for a
> sender, in a message, is when the content gets unacceptable (spam, too big).
> >
> > We have about 30 categories to explain what type of error occurred
> (available on request).
> >
> > Met vriendelijke groet,
> >
> >
> > David Hofstee
> > Deliverability Management
> > MailPlus B.V. Netherlands (ESP)
> >
> > Van: mailop [mailto:mailop-boun...@mailop.org] Namens Brandon Long
> > Verzonden: donderdag 10 december 2015 22:23
> > Aan: Dave Warren
> > CC: mailop
> > Onderwerp: Re: [mailop] Delivery to gmail via IPv6
> >
> > I was just discussing this issue with our support folks, and we're
> looking at improving ours for this reason.  We also see a remarkable number
> of our NDRs marked as spam, especially by those whose primary language
> isn't English.
> >
> > We'll definitely still include the technical information, but it'll be
> further down.
> >
> > And we'll do our best with handling the remote server's error messages,
> but ugh.  It's too bad that the extended status codes are still so
> generic... though, as our tech writer and ux folks pointed out, really, all
> the user cares about is "did I do something wrong? Is there something else
> I can do?"
> >
> > Brandon
> >
> > On Thu, Dec 10, 2015 at 12:18 PM, Dave Warren 
> wrote:
> > And unfortunately the friendlier they are,