| Re: FORMS, validating mail was sent [message #181920 is a reply to message #181918] |
Sun, 23 June 2013 17:00   |
bill
Messages: 310
Registered: October 2010
Karma:
|
Senior Member |
|
|
Hi,
I've top-posted for two reasons: 1, It's a lot of good info that bears
repitition at lease once, and 2, it's a long post so rather than have
people CTRL-Ending or worse scrolling to the bottom for the response,
this makes it more immediate.
That's a great response and verifiable, which many are not. Some of it I
already knew, a lot of it was great clarification, and I learned a lot.
KUDOS!
Twayne`
On 2013-06-23 7:13 AM, Thomas 'PointedEars' Lahn wrote:
> Gordon Burditt wrote:
>
>> + Your mail was dropped on the floor for having an invalid
>> From: address. Valid From: addresses likely include ONLY
>> those with the host name of the server you are sending
>> from and a known valid user on that system. Typically
>> only a few users like root can send mail with 'fake'
>> (off-system) From: addresses. Hint: Do NOT put a
>> user-supplied email address in the From: header.
>
> Utter nonsense. By that logic, Web-mail like GMail could not possibly work,
> and it would not be possible to have large e-mail providers in the first
> place (because the host name of their servers very likely differs from the
> domain of the From header field address).
>
> Valid From addresses include all that meet the Address Specification in
> RFC 5322, instead. This is a purely *syntactical* determination. It is the
> fact that even addresses for which there are no mailboxes at the sending
> server can be used in the From header field value, and that afterwards
> checking of addresses is unreliable, that allows spammers to thrive.
>
> One must differentiate between the address used as parameter for the MAIL
> FROM (SMTP) command (the “Envelope-From”), and the “From” Internet message
> header field. The latter can be anything; the former can, in theory, be
> anything unless the *sending* MTA enables counter-measures. It is not
> possible to change the Envelope-From with simple PHP commands like mail() as
> that is determined by the MTA (like sendmail) used by the PHP executable.
>
> The only good part of this answer is the notion that you invite spammers if
> you let the end user specify the From header field address without
> authentification; so you should not do that, indeed. The /modus operandi/
> of spammers and phishers is to harvest or buy e-mail addresses from various
> sources and use them also in the “From” header field value to make the
> message look to the recipient like a legitimate e-mail (at first). This
> kind of network abuse is also supported by “open relays” – MTAs that would
> accept and transfer mail for any MAIL FROM to any RCPT TO.
>
>> + The intended recipient has a slow DNS server. If you
>> send emails to 100 recipients at a time, it is likely
>> that at least a couple of them have slow DNS servers or
>> overloaded mail servers. The mail will stay in the queue
>> until the message has been delivered to all recipients,
>> and that can take days, even if 98 of them were delivered
>> in the first minute.
>
> Utter nonsense. DNS is only used to resolve the target host of the message,
> specifically to retrieve the host name from the “MX” or “A”/“AAAA” record of
> the target domain, and subsequently to resolve the IP address for that host
> name from its “A” or “AAAA” record (this double-handshake is intended as a
> safety feature of DNS/SMTP: there must be a host *name* for an MX). There
> are no DNS servers anywhere that have a respond time of minutes that would
> suggest the remote possibility of a delay of days because of DNS issues
> (after all, a backup DNS server is strongly recommended, and there are non-
> authoritative answers).
>
> When in rare cases e-mails arrive days later, it is usually due greylisting
> and a long sender or receiver message queue that needs to be worked through;
> not DNS issues at the receiver's (BTST). Also, the mail queue contains a
> *copy* of the message for each recipient (not least because in the worst
> case each copy must be sent to a different host). Only those copies that
> have not been sent are still in the queue, not the single original message
> (“the mail”) itself.
>
> “Overloaded mail servers” also are unlikely to be a reason why a message
> stays in the sending queue, because receiving MTAs *also* have an *incoming*
> message queue which is worked through to put the message into the
> corresponding receivers' mailboxes. Overloading is more likely the reason
> why the message does not arrive at the recipient's mailbox sooner, but that
> has nothing to do with the message transfer between the MTAs, and nothing
> with the sending MTA's outgoing message queue.
>
>>> But you cant execute that without root privileges. Which means having
>>> that level of access to the machine and writing an su 'ed wrapper in C
>>> and calling that instead.
>>
>> Sometimes you can get a queue count without root privileges. The
>> program that comes with the MTA for this is likely already setuid-root,
>> and you may be able to configure allowing ordinary users to get a
>> queue count.
>
> man sudo
>
>
> PointedEars
>
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]