On 13 Aug 2004 at 8:41, Steffen Kaiser wrote:
> > It's an optional part of SMTP that doesn't have to be supported, and
> > does have some security issues.
>
> Which ones?
> It simply triggers a queue run filtering mail for a target server.
Depending on the ability of your sendmail installation t
On Thu, 12 Aug 2004, Kelson Vibber wrote:
Sure, PGP and S/MIME are probably more elegant solutions. But if you think
it's hard getting mail server admins to agree on and implement something like
SPF, just try convincing every man, woman and child on the Internet to
digitally sign every piece of
On Thu, 12 Aug 2004, Jeff Rife wrote:
And what do you think the command ETRN is for?
It's an optional part of SMTP that doesn't have to be supported, and
does have some security issues.
Which ones?
It simply triggers a queue run filtering mail for a target server.
Bye.
--
Steffen Kaiser
___
On 12 Aug 2004 at 12:33, Kelson Vibber wrote:
> - Some of those criteria (such as spam filters) are hard to keep in sync
> across multiple implementations.
Spam isn't really a big deal in the bounce area.
For us, once it hits analysis (SpamAssassin through MIMEDefang), we
never send anything b
On 12 Aug 2004 at 10:14, Kelson Vibber wrote:
> 1. Spammer targets the backup MX (us), assuming it's less protected.
> 2. We queue, reject, or discard the message.
> 3. Mail ends up at customer's primary mail server, which rejects *on
> different criteria*.
> 4. Customer's server issues an SMTP r
On 12 Aug 2004 at 10:20, Cor Bosman wrote:
> > In any case, this is in reality no different from a client calling up
> > and getting the mail from a server. Because the ISP is the only MX, it
> > should know about all the deliverable addresses, simply to avoid
> > dictionary e-mailings to thes
Kelson Vibber wrote:
> Bad recipients are NOT the only problem!
I agree. Rejecting-bad-emails-at-the-gateway is a Good Idea (tm), but it doesn't
solve everything.
[EMAIL PROTECTED] 805.964.4554 x902
Hispanic Business Inc./HireDiversity.com Software Engineer
perl -e"
At 10:55 AM 8/12/2004, [EMAIL PROTECTED] wrote:
Kelson Vibber wrote:
> Let's try another ISP-as-MX scenario, this time where the company runs its
> own mail server as primary MX, but uses the ISP's server as a secondary:
Whoa... stop right there. If ISPs do this, there's a growing onus to
maintai
EMAIL PROTECTED]
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:mimedefang-
> [EMAIL PROTECTED] On Behalf Of David F. Skoll
> Sent: Thursday, August 12, 2004 2:38 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [Mimedefang] Deadline for SPF records *long w/morbid
>
> >> Again, this completely solves the issue of forged return address
> >> bounce e-mails.
> >
> > Actually, no it doesn't.
> >
> > Let's try another ISP-as-MX scenario, this time where the company runs its
> > own mail server as primary MX, but uses the ISP's server as a secondary:
>
> Whoa...
On Thu, 12 Aug 2004 [EMAIL PROTECTED] wrote:
> But accept-everything-and-send-manual-undeliverable-reports-later is
> becoming less and less acceptable of a strategy.
I concur. I suspect ISPs will find it less and less attractive to
offer backup MX services, and will either get out of that busin
[EMAIL PROTECTED] wrote on 08/12/2004 01:55:55
PM:
> But accept-everything-and-send-manual-undeliverable-reports-later is
> becoming less and less acceptable of a strategy.
Hear! Hear!!
I looked at a number of spam filters that did this before I came across
MIMEDefang (and CanIT Pro which we u
Kelson Vibber wrote:
> At 06:27 PM 8/11/2004, Jeff Rife wrote:
>> it is the responsibility of the MX machine to know what is and is
>> not deliverable.
>>
>> Again, this completely solves the issue of forged return address
>> bounce e-mails.
>
> Actually, no it doesn't.
>
> Let's try another IS
At 06:27 PM 8/11/2004, Jeff Rife wrote:
it is the responsibility of the MX machine to know what is and is not
deliverable.
Again, this completely solves the issue of forged return address bounce
e-mails.
Actually, no it doesn't.
Let's try another ISP-as-MX scenario, this time where the company r
[EMAIL PROTECTED] wrote on 08/12/2004 04:20:31
AM:
> And what do you think the command ETRN is for? One could give these
hosts
> a lower MX, but on the other hand, if they're almost never online you'd
have
> to wonder if thats a good thing.
ETRN requires the queueing MX to be able to resolve
> > This is not true. Im not sure how many 'most' ISPs you are talking
> > about, but I know quite a few ISPs that accept all email for a
> > domain and forward to a customer. This is most prevalent in
> > dialup/isdn situations where you basically 'store and forward' all
> > email for customers t
On 11 Aug 2004 at 10:38, Cor Bosman wrote:
> > The companies that offer #2 also offer ways for you to retrieve the e-
> > mail with your MUA software, so they don't *want* to deal with passing
> > it on to an MTA.
>
> This is not true. Im not sure how many 'most' ISPs you are talking
> about, bu
> > >>If your ISP allows you to have mail servers behind theirs and they are
> > >>the "front line MX" and forward everything to you, then your ISP is
> > >>really odd.
> > >
> > >
> > > This is not odd at all.
> >
> Now, for *real* ISPs (like, say Comcast, who provide both connectivity
> *a
On 10 Aug 2004 at 14:29, Ben Kamen wrote:
> >>If your ISP allows you to have mail servers behind theirs and they are
> >>the "front line MX" and forward everything to you, then your ISP is
> >>really odd.
> >
> >
> > This is not odd at all.
>
> I concur.
>
> This is not odd at all and is ac
Cor Bosman wrote:
How about "scaling"? I'm pretty sure my ISP will run (screaming, no
doubt), from a scenario in which they rely on their customers to keep
their list of valid addresses current.
If your ISP allows you to have mail servers behind theirs and they are
the "front line MX" and forward
> > How about "scaling"? I'm pretty sure my ISP will run (screaming, no
> > doubt), from a scenario in which they rely on their customers to keep
> > their list of valid addresses current.
>
> If your ISP allows you to have mail servers behind theirs and they are
> the "front line MX" and forward
On 10 Aug 2004 at 9:04, Graham Dunn wrote:
> > There is no reason a backup MX server can't know if an address is valid
> > or not.
>
> How about "scaling"? I'm pretty sure my ISP will run (screaming, no
> doubt), from a scenario in which they rely on their customers to keep
> their list of valid
On 10 Aug 2004 at 9:00, Joseph Brennan wrote:
> --On Monday, August 9, 2004 11:17 PM -0400 Jeff Rife <[EMAIL PROTECTED]>
> wrote:
>
> >> At the core, this solution ignores the concept and purpose of a backup MX
> >> which is a reality and necessity for many companies where email is
> >> critical
On Mon, Aug 09, 2004 at 11:17:41PM -0400, Jeff Rife wrote:
> On 9 Aug 2004 at 21:03, Kevin A. McGrail wrote:
>
> > > If the receiving MX servers always knew all valid recipient addresses
> > > *at (E)SMTP connection time*, then there would be no bounces...only
> > > rejections.
> > >
> > > This so
--On Monday, August 9, 2004 11:17 PM -0400 Jeff Rife <[EMAIL PROTECTED]>
wrote:
At the core, this solution ignores the concept and purpose of a backup MX
which is a reality and necessity for many companies where email is
critical.
I dispute this statement. If the MX host is configured differen
Jeff Rife said:
headers become the norm.
>
> If the receiving MX servers always knew all valid recipient addresses
> *at (E)SMTP connection time*, then there would be no bounces...only
> rejections.
>
> This solves the problem without introducing anything new to (E)SMTP.
Even though my gateway ma
On 9 Aug 2004 at 21:03, Kevin A. McGrail wrote:
> > If the receiving MX servers always knew all valid recipient addresses
> > *at (E)SMTP connection time*, then there would be no bounces...only
> > rejections.
> >
> > This solves the problem without introducing anything new to (E)SMTP.
>
> At the
> If the receiving MX servers always knew all valid recipient addresses
> *at (E)SMTP connection time*, then there would be no bounces...only
> rejections.
>
> This solves the problem without introducing anything new to (E)SMTP.
At the core, this solution ignores the concept and purpose of a backu
On 9 Aug 2004 at 20:21, Kevin A. McGrail wrote:
> I thought about the statement below a lot because it seemed correct at first
> that pushing valid emails to all the gateways would solve the issue.
> However, the more I thought about it, invalid bounces are a big problems and
> SPF is a reasonable
Re: SPF Solving Invalid Bounces
I thought about the statement below a lot because it seemed correct at first
that pushing valid emails to all the gateways would solve the issue.
However, the more I thought about it, invalid bounces are a big problems and
SPF is a reasonable solution to start cutti
30 matches
Mail list logo
